Automatizaciones de Cursor: guía práctica de agentes de código siempre activos

El verdadero cuello de botella en el desarrollo de software ya no es escribir código: casi cualquier desarrollador en un equipo, sea del tamaño que sea, cuenta al menos con un agente que le ayuda a desplegar. Los agentes de programación ya están integrados en los flujos de trabajo del día a día, y la implementación ha dejado de ser la parte más lenta del sistema.

Cursor Automations está diseñado para cerrar esa brecha. En lugar de pedirle cosas al agente una y otra vez, defines cuándo debe actuar. Se dispara un desencadenante, unas instrucciones guían lo que hace y se ejecuta solo. Se abre un pull request, y se revisa. Llega un informe de bug a Slack, y se gestiona. Se ejecuta una programación y se genera un informe.

En este tutorial te mostraré cómo configurar las automatizaciones de Cursor de principio a fin. Vas a crear dos automatizaciones: una revisión de PR y un monitor programado de cobertura de tests. Por el camino, desglosaré cómo estructurar las instrucciones y conectar herramientas y MCP para que las automatizaciones se comporten como esperamos.

Un apunte antes de empezar: Automations sigue en desarrollo y el panel en cursor.com/automations está evolucionando. Si cuando leas esto alguna etiqueta de menú o botón ha cambiado, la lógica subyacente seguirá siendo la misma.

¿Qué son las automatizaciones de Cursor?

Las automatizaciones de Cursor son un sistema para ejecutar automáticamente los agentes en la nube de Cursor, activados por eventos en tus herramientas de desarrollo o por una programación que definas.

En el modo Agent de Cursor, como explicamos en nuestro curso Software Development with Cursor, empiezas cada sesión abriendo un chat y escribiendo un prompt, y el agente se ejecuta en tu máquina local mientras lo acompañas.

En automations, la señal de inicio llega de otro punto de tu stack, y el agente hace su trabajo en un sandbox en la nube sin necesidad de que lo vigiles.

Las automatizaciones incluyen eventos de activación que he resumido en la tabla de abajo, pero también puedes configurar activadores personalizados con webhooks. Una automatización puede tener más de un activador y se ejecuta siempre que se dispare cualquiera de ellos.

Cada uno de esos tipos de activadores sustituye un momento de tu día en el que, de otro modo, tendrías que darte cuenta de algo, cambiar de contexto al modo Agent de Cursor y pedir ayuda. 

El activador de pull request es probablemente el primero que crearás. Así es como se ve el ciclo de vida de un PR antes y después de añadir una automatización que vigile tu repositorio.

Lo que cambia en esa segunda columna no es la velocidad de cada paso, sino que tu atención deja de ser el factor que limita el ritmo de todo el proceso.

Cómo funcionan las automatizaciones de Cursor por dentro

Todas las automatizaciones siguen el mismo pipeline bajo el capó. Cuando se dispara el activador que definas, Cursor levanta un sandbox nuevo en la nube, clona tu repositorio en él y lanza un agente que sigue tus instrucciones usando las herramientas, conexiones MCP y modelo configurados. Ese repositorio no tiene por qué estar en GitHub: los repos alojados en Cursor Origin, el propio forja de Git de Cursor, también funcionan con agentes en la nube y automatizaciones.

El agente verifica su salida antes de finalizar y después publica el resultado donde hayas configurado: un comentario en el PR, un mensaje en Slack, un ticket en Linear o abriendo un nuevo pull request.

Dos propiedades definen cada automatización que crees:

• El sandbox se ejecuta íntegramente en la nube de Cursor, no en tu portátil. Sigue funcionando incluso cuando tu máquina está apagada.
• Cada ejecución se hace en aislamiento. Varias automatizaciones pueden correr en paralelo sin interferirse. Cursor también ha dicho que internamente ejecuta cientos de automatizaciones por hora.

Además hay una herramienta de memoria, como ves en la vista previa de abajo, que permite que tu automatización persista estado entre ejecuciones, algo importante más adelante cuando construyamos el monitor de cobertura programado.

Volveré a ella cuando construyas el monitor de cobertura programado.

Automatizaciones de Cursor frente al modo Agent

Si ya usas Cursor con frecuencia, la gran pregunta es cuándo usar automatizaciones en lugar del modo Agent. Yo no usaría Automations para tareas puntuales. Están pensadas para trabajo repetitivo o que depende de eventos externos.

Cuando la elección no está clara, me ayuda compararlas así:

Yo lo pienso así: si una tarea empieza con «siempre que» o «cada vez que», encaja en Automations.

Por ejemplo: «Cada vez que se abre un PR, o siempre que llega un informe de bug a #support, crea un ticket en Linear». El activador es recurrente y predecible.

Si empieza con «ahora necesito refactorizar este módulo», pertenece al modo Agent. Tú decides cuándo es «ahora».

Si quieres explorar Cursor antes de meterte con las automatizaciones, nuestra guía completa de Cursor 2.0 te lleva por la interfaz de Agents, Composer y el flujo multiagente con un proyecto completo en Python.

Acceder al panel de Automations

El panel de automatizaciones de Cursor está en cursor.com/automations. Inicia sesión con tu cuenta de Cursor y llegarás al panel principal, como ves a continuación:

Vamos a desglosar lo que vemos en el panel.

Tarjetas de resumen o indicadores de estado en la parte superior

Las tarjetas nos dan una instantánea de salud de todo lo que has ejecutado. Incluyen:

• Automatizaciones totales (cuántas tienes configuradas) 
• Correctas (ejecuciones completadas, con su tasa de éxito)
• Fallidas (ejecuciones con error)
• Historial de ejecuciones (al hacer clic, muestra el volumen de ejecuciones en el tiempo)

El cuadro de entrada de instrucciones

El campo de entrada es la forma más rápida de crear una nueva automatización sin abrir el formulario completo. Describe la tarea y Cursor genera la estructura de la automatización.

Si estás empezando, te recomiendo hacerlo aquí. Decide qué quieres automatizar y luego escribe un conjunto estructurado de instrucciones para que el agente lo siga cada vez que se dispare el activador. 

Cuando pulses el botón de la flecha, Cursor usará esas instrucciones para generar la automatización por ti, precargando el nombre, los activadores y las herramientas necesarias.

No trates estas instrucciones como un prompt normal, sino como una especificación que el agente ejecuta cada vez. Volveré a esto cuando te enseñe a crear tu primera automatización más adelante.

El conmutador "mías / del equipo" y el botón + nueva automatización

El conmutador filtra entre tus automatizaciones y las del equipo. 

El + New abre una página para configurar una nueva automatización:

El botón + New Automation es la alternativa más detallada al cuadro de instrucciones en línea si quieres configurar manualmente desde cero el activador, las instrucciones y las conexiones de herramientas.

Tu lista de automatizaciones existentes

La tabla muestra todas las automatizaciones que has creado, incluidas las herramientas usadas y el historial de ejecuciones.

Al hacer clic en cualquiera se abre su página de ajustes y su historial:

Sección de plantillas sugeridas

Debajo de la lista de automatizaciones anteriores hay una cuadrícula de tarjetas de plantillas. Las plantillas ofrecen automatizaciones prediseñadas que puedes modificar en lugar de empezar de cero.

Las plantillas de automatización de Cursor son la forma más rápida de poner en marcha una automatización el primer día. Si estás creando tu primera automatización, comprueba si hay una plantilla que se ajuste a lo que quieres automatizar y empieza desde ahí.

Las plantillas te dan criterios sobre cómo deben ser unas buenas instrucciones y qué conexiones de herramientas o MCP necesitas.

Cuenta y costes a tener en cuenta

Las automatizaciones de Cursor se ejecutan en la infraestructura en la nube de Cursor, lo que requiere acceso a cloud agents, incluido en los planes de pago. Cada ejecución consume créditos según el modelo y el tiempo de ejecución.

Las automatizaciones admiten tres niveles de visibilidad según su modelo de permisos:

• Privada: solo tú puedes verla y se factura a tu cuenta.
• Visible para el equipo: otros pueden ver tus automatizaciones y su historial, pero sigue facturándose a ti.
• Propiedad del equipo: la automatización se imputa al pool compartido del equipo y la gestionan los administradores.

Elegir bien el nivel importa porque determina de quién son los créditos que usa la automatización cada vez que se ejecuta. Mantén los experimentos en privado hasta confiar en la salida. Cuando una automatización pase a formar parte del flujo de trabajo del equipo, muévela al nivel de propiedad del equipo.

El principal modo de fallo es dejar que una automatización se ejecute demasiado amplia, demasiado pronto. Si se activa en cada push de un repo con mucha actividad, puede acumular consumo rápido sin que te des cuenta. Empieza estrecho, déjala correr unos días, revisa con qué frecuencia se dispara y luego decide si ampliar o escalar.

Crea tu primera automatización en Cursor: revisión de código en PR

La revisión de código en PR es la primera automatización ideal porque el ciclo de feedback es corto y las consecuencias de una mala ejecución son bajas. Si el agente publica un comentario útil, lo vemos al instante en el PR. Si publica algo fuera de lugar, lo ignoramos y no se envía nada.

Te guiaré para construir tu primera automatización en cinco pasos:

1. Conectar tu repositorio de GitHub
2. Configurar los activadores de GitHub
3. Redactar las instrucciones del agente (con estructura clara y qué evitar)
4. Añadir la herramienta de comentario en Pull Request de GitHub
5. Desplegar la automatización

Paso 1: conectar tu repositorio de GitHub

Antes de que el agente pueda revisar un pull request, necesita acceso a un repositorio. Cursor accede a tu repo a través de una integración nativa como GitHub App. Sin esa conexión, el agente de la automatización no puede ver tu código, leer los diffs de PR ni responder con feedback, así que nada funciona realmente.

Si aún no lo has hecho:

1. Instala la GitHub App de Cursor en tu cuenta u organización de GitHub y concédele acceso a los repos que quieras que las automatizaciones vigilen.
2. Conecta tu cuenta de GitHub en el panel en la pestaña Integrations. 

Una vez activa la conexión, tus repos estarán disponibles al configurar el activador de la automatización.

Paso 2: configurar los activadores

Desde el panel de automatizaciones:

1. Haz clic en + New Automation para crear una automatización.
2. Ponle nombre. Puedes llamarla PR Code Review – Open & Push – Comment Only
3. En la sección de activadores, haz clic en Add trigger y selecciona GitHub. Elige PR opened y PR pushed como eventos de activación.
4. Selecciona el repositorio objetivo.

Si te saltaste el paso 1 o es la primera vez que conectas GitHub a las automatizaciones de Cursor, se te pedirá que te autentiques. 

En la vista previa de abajo muestro cómo configurarlo y seleccionar el repositorio objetivo una vez completes la autorización:

Nota: Podemos agrupar varios eventos de activación en una sola automatización cuando las instrucciones no cambian según el evento que se dispare. Pero si la profundidad o el propósito de la revisión cambian según el evento, mejor usa automatizaciones separadas.

Ahora la automatización sabe cuándo ejecutarse. El siguiente paso es decirle qué hacer.

Paso 3: escribir instrucciones eficaces

Las instrucciones son la mayor palanca para que nuestra automatización produzca resultados útiles. El agente las usa para entender qué es «bueno». Instrucciones vagas llevan a resultados inconsistentes.

Antes de escribirlas, tenemos que entender qué estamos definiendo. No estamos dando un prompt puntual. Estamos fijando un comportamiento que el agente seguirá cada vez que se dispare el activador. La calidad de la automatización depende de lo claro que especifiquemos ese comportamiento.

Esta es la estructura que recomiendo:

• Define el rol: marca la perspectiva y el tono. Por ejemplo: «Eres una persona revisora de seguridad para pull requests».
• Define el objetivo: sé claro sobre qué significa éxito. Por ejemplo: «Detecta y explica con claridad vulnerabilidades reales».
• Delimita el alcance: indica en qué debe centrarse el agente. Por ejemplo: «Revisa solo el código añadido o modificado».
• Esboza el flujo de trabajo: dale una forma clara de abordar la tarea. Por ejemplo: «Inspecciona los cambios, sigue los inputs y verifica las protecciones».
• Fija exclusiones: di explícitamente qué ignorar para reducir ruido.
• Define el comportamiento y la salida: cómo debe actuar y cómo debe presentar los resultados.
• Marca límites: qué no debe hacer nunca.

Escribe las instrucciones como escribirías un runbook: específicas, ordenadas, con criterios de aceptación claros y límites explícitos.

Ejemplo de buena instrucción

Esta es la instrucción que usé para esta automatización de revisión de PR. Puedes copiarla en tu cuadro de instrucciones, pero modifícala para tu caso:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.Con la tecnología de

Aquí tienes la instrucción en el cuadro de entrada de instrucciones:

Este prompt es sencillo, pero sigue una estructura clara y específica. 

Ejemplo de mala instrucción

Evita instrucciones vagas como:

Review this PR and give feedback on any issues you notice.Con la tecnología de

Sin estructura, restricciones ni prioridades, el agente tendrá que adivinar qué significa «issues», lo que lleva a feedback genérico y superficial en lugar de resultados fiables.

Paso 4: añadir herramientas

Abre el panel de herramientas dentro del editor de automatizaciones. Para esta automatización, ve a la sección de GitHub y selecciona la herramienta Comment on Pull Request. Asegúrate de que la aprobación de PR esté deshabilitada, como en la vista previa de abajo, para que la automatización solo pueda comentar, no aprobar cambios.

La herramienta Comment on Pull Request permite al agente publicar hallazgos en el PR. No requiere una conexión aparte porque se apoya en la misma GitHub App de Cursor que autorizaste en el paso 1.

Si quisiéramos enviar la salida a otros servicios (como publicar en Slack), elegiríamos la herramienta correspondiente o añadiríamos una conexión MCP. Para esta automatización, la herramienta de comentarios es suficiente.

Paso 5: desplegar y monitorizar tu primera ejecución

Cuando los activadores, instrucciones y herramientas estén listos, haz clic en Create para guardar la automatización; se abrirá la página de configuración de la automatización, como ves a continuación:

Como ya hemos desplegado la automatización, necesitamos activar una ejecución y ver qué produce el agente.

Abre un pull request en borrador en tu repositorio conectado. Esto dispara el activador de PR abierto y debería aparecer una nueva entrada en el historial de ejecuciones en segundos, como ves aquí:

Abre esa ejecución y comprueba tres cosas:

• Tiempo de ejecución: cuánto tarda. Varía según el tamaño del diff, el modelo y la complejidad de las instrucciones.
• Llamadas a herramientas: ¿qué archivos y herramientas se usaron? Si el agente lee archivos no relacionados, revisa tus instrucciones.
• Salida: lo que se publicó en GitHub. Compáralo con tus instrucciones.

Abajo tienes un resumen de la ejecución de mi automatización. Verás que duró seis minutos, realizó acciones y publicó la revisión del PR con la herramienta PostReviewCommentOnPr:

A continuación, un ejemplo de comentario que el agente publicó en mi PR:

A veces la salida puede no acertar; cuando pasa, normalmente el problema está en las instrucciones. Ajusta la parte que controla el comportamiento que quieres cambiar, sube un nuevo commit para disparar otra ejecución y revisa el resultado.

En estas primeras ejecuciones conviene empezar sencillo para mantener el riesgo bajo. En este caso, limitamos la automatización solo a comentarios, lo que nos permite confirmar cómo se comporta con seguridad. Cuando la salida sea consistente, pásala a uso real y conecta otras herramientas más allá de GitHub para ampliar lo que puede hacer.

Conectar más herramientas con MCP

La automatización de revisión de PR que acabamos de crear se ejecuta sobre GitHub. Lee el diff y publica comentarios en el pull request usando la herramienta de comentario en PR de GitHub. Pero si queremos que el agente haga algo más que revisar código, necesitamos conectar otras herramientas. Para eso está el Model Context Protocol (MCP).

MCP es una interfaz estándar que permite a los agentes usar herramientas externas sin integraciones a medida. Sin MCP, cada herramienta requeriría su propia configuración y mantenimiento. 

Con MCP, una vez conectamos una herramienta compatible en el panel de herramientas de la automatización, el agente puede usarla a través de la misma interfaz.

MCP permite que la misma automatización haga más y actúe en otras herramientas. Tu automatización de revisión ya comenta en GitHub. Añade Slack y podrá publicar actualizaciones en un canal. Añade Linear y podrá crear tickets. Añade Datadog y podrá sacar logs. Cada conexión amplía lo que puede hacer sin cambiar su lógica central.

Las automatizaciones de Cursor incluyen un conjunto integrado de integraciones MCP como Slack, Linear, ClickUp, Datadog, Notion y más. Y como MCP es un estándar abierto, podemos conectar cualquier herramienta compatible del mismo modo.

Encontrarás MCP en Tools -> MCP server en la página de ajustes de la automatización. Haz clic en + New Connection para explorar, luego instala y conecta la herramienta que necesites.

Aquí tienes una vista previa de cómo añadirlas:

En la siguiente sección te guiaré para añadir una conexión MCP de Slack a la automatización de revisión de PR.

Añadir una conexión MCP de Slack

GitHub hace que la automatización lea y comente nuestro código. Slack hace que hable con el equipo.

Desde el panel de Tools, haz clic en Add Tool or MCP, selecciona MCP Server y luego elige +New Connection. En el panel que se abre, busca Slack y selecciona el servidor MCP de Slack. 

Slack suele venir ya instalado; si no, instálalo y sigue el flujo de OAuth para autorizar tu espacio de trabajo. Una vez conectado, aparecerá en tu panel de herramientas, como muestro en la vista general de abajo:

No elegimos un canal de destino durante la configuración de la conexión. MCP da al agente acceso a nivel de espacio de trabajo a todos los canales públicos. Controlamos exactamente dónde publica indicando el canal en las instrucciones, por ejemplo: «Envía un mensaje a Slack a #pr-alerts si se encuentra algún issue crítico».

Nota: el MCP de Slack solo funciona con canales públicos, y el canal de destino debe tener invitado al bot de Cursor antes de que la automatización pueda publicar. Tras el flujo OAuth debería aparecer un bot de Cursor en tu espacio de trabajo. Ve al canal y ejecuta /invite @Cursor para añadirlo.

Si no ves el bot @Cursor, puede que la autorización haya fallado. Ve a dashboard -> integrations, haz clic en Manage junto a Slack y repite el OAuth.

Si quieres profundizar en MCP, nuestro tutorial de FastMCP 2.0 explica cómo crear un servidor MCP personalizado desde cero e integrarlo en Cursor.

Combinar activadores y herramientas

Con la conexión MCP de Slack, podemos ampliar la automatización de revisión de PR. Mantendremos los mismos activadores de PR de GitHub y la herramienta de comentar en PR de GitHub. Pero ahora el agente también puede publicar hallazgos críticos en #pr-alerts a través del MCP de Slack.

Añade este bloque al final de las instrucciones que escribimos en el paso 3 al crear la primera automatización:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.Con la tecnología de

Esa última línea importa más de lo que parece. Sin ella, #pr-alerts puede llenarse rápido de notificaciones de «todo bien» y perder su valor. Para mí, indicar al agente cuándo no actuar es tan importante como decirle cuándo actuar.

A continuación tienes las salidas de una ejecución de prueba en mi repositorio.

Vista de un comentario que el agente publicó al abrir el PR en mi GitHub (mediante la herramienta de comentario en PR de GitHub):

Vista de la notificación en Slack que el agente envió a mi canal #pr-alerts en la misma ejecución mediante la conexión MCP de Slack:

En este punto tienes una automatización funcional que revisa cada PR, publica comentarios en GitHub y eleva los issues críticos a Slack. Ese es el patrón básico. 

En la siguiente sección, crearemos una segunda automatización siguiendo el mismo flujo: un activador, instrucciones y las herramientas que el agente necesita para producir la salida.

Crear una segunda automatización: monitor de cobertura de tests programado

La automatización de revisión de PR reacciona a eventos de GitHub. Las automatizaciones programadas funcionan distinto: definimos cuándo debe ejecutarse el agente y este se pone en marcha a esa hora independientemente de lo que haya pasado en el repo.

La automatización que vamos a crear se ejecuta cada día a las 9:00, revisa el código fusionado a la rama principal en las últimas 24 horas, identifica áreas con cobertura de tests insuficiente y publica un resumen en #repo-coverage en Slack.

Configurar un activador cron y la herramienta

Desde el panel de automatizaciones:

• Haz clic en + New para crear una automatización.
• Ponle nombre Daily Coverage Check – Main Branch.

Configura el activador

• En Triggers, selecciona Scheduled.
• Elige Every... > Day y fija la hora a las 9:00 AM.
• Si necesitas otro formato, como solo laborables, usa Custom (cron)
• Como los activadores programados no infieren repositorio, selecciona el repo y la rama de destino (main).

Añade la herramienta Send to Slack

Aquí te presento la herramienta Send to Slack disponible en los ajustes de la automatización. Es distinta del MCP de Slack que usamos antes. La usamos para enviar mensajes a un canal concreto, mientras que el MCP de Slack ofrece acceso a nivel de espacio de trabajo y permite al agente publicar en cualquier canal definido en las instrucciones.

Para añadir la herramienta Send to Slack, selecciónala en la sección de herramientas y especifica el canal de destino para la salida de la automatización. Así debería verse:

Redactar las instrucciones para una tarea programada

En la automatización de revisión de PR, el agente reacciona a un pull request y publica feedback. En las automatizaciones programadas no hay input entrante. El agente comienza solo, así que debemos dejar claro por dónde empezar, qué comprobar y qué publicar.

Aquí la herramienta de memoria es importante. La comparación de cobertura solo funciona si el agente conoce los números de ayer. Debemos decirle qué clave leer, qué comparar y qué guardar al final. Si lo dejamos difuso, los resultados pueden variar entre ejecuciones.

Este es el conjunto de instrucciones que usé:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).Con la tecnología de

A continuación, te muestro las salidas de mi automatización programada a las 9:00.

Aquí está el resumen de la automatización. En mi caso, la cobertura se mantuvo por encima del umbral, así que solo publicó un estado en verde en el canal de Slack:

Este es el mensaje en Slack. Es la primera ejecución del monitor de cobertura, así que no esperaba mucho. También puedes ver que la ejecución se guardó en memoria como base para la próxima comparación:

Viendo la ejecución anterior, destacan dos partes de las instrucciones. 

Primero, define tanto la ruta de aviso como la de verde. La ruta verde es necesaria. Si solo definimos qué pasa cuando algo va mal, la automatización se queda en silencio cuando todo va bien. En un canal de monitorización, ese silencio parece un fallo. El estado en verde confirma que la ejecución terminó.

Segundo, la lectura y el guardado en memoria son explícitos. El agente tiene una herramienta de memoria, pero no la usará de forma fiable para comparar si no se le indica. Si lo dejamos implícito, los resultados pueden variar entre ejecuciones. Debemos especificar exactamente qué clave leer, qué comparar y qué guardar.

En la imagen de abajo puedes ver que el agente guardó mi automatización:

En la siguiente sección, cubriré los errores comunes y las buenas prácticas para sacarle más partido a tus automatizaciones.

Automatizaciones de Cursor: errores comunes y buenas prácticas

La mayoría de problemas con automatizaciones provienen de un conjunto pequeño de errores previsibles. Son fáciles de evitar cuando los conoces, pero caros de depurar cuando no.

Errores comunes a evitar

• Instrucciones vagas: un modo de fallo típico. Cualquier cosa como «revisa el código», «busca problemas» o «resume cambios» obliga al agente a adivinar qué quieres decir, lo que produce salidas inconsistentes. Si una frase tiene un verbo sin objeto o condición claros, reescríbela antes de desplegar.
• Alcance excesivo: no combines chequeos de seguridad, estilo, rendimiento y cobertura en una única automatización. Complica depurar fallos. Las automatizaciones acotadas son más fáciles de entender. 
• Saltar la fase de calibración: no actives opciones como auto-approve o auto-merge al principio. Haz que las primeras ejecuciones sean al menos solo de comentarios. Estas ejecuciones revelan casos límite en tu base de código. Trátalo como validación antes de producción.
• Configuración de canales de Slack: los activadores de Slack solo funcionan en canales públicos, así que si una automatización de Slack no hace nada, comprueba la visibilidad del canal y asegúrate de que el bot @Cursor esté invitado en ese canal.

Buenas prácticas para automatizaciones fiables

• Una tarea por automatización: cada automatización debe hacer una cosa bien definida. Así es más fácil aislar fallos y aplicar correcciones.
• Empieza desde un estado limpio: haz commit de tu árbol de trabajo antes de que un agente haga cambios, para tener siempre un diff claro con el que comparar.
• Trata las primeras ejecuciones como calibración: espera algo de ruido al principio, revisa salidas, ajusta instrucciones y vuelve a ejecutar hasta estabilizar el comportamiento.
• Usa nombres claros y descriptivos: nombres como PR Code Review – Open & Push – Comment Only son más útiles que etiquetas genéricas cuando vuelvas a ellas.
• Revisa el historial de ejecuciones con frecuencia: durante las primeras semanas, esto te da intuición de qué es un comportamiento normal y te facilita detectar problemas después.

Reflexiones finales

Cursor Automations lleva la programación con agentes de un flujo interactivo a un sistema dirigido por eventos. En el modo Agent de Cursor, abrimos un chat y pedimos al agente que revise código, refactorice funciones o investigue problemas. En automations, no iniciamos el trabajo directamente. Activadores como un pull request, un mensaje de Slack o una programación ponen en marcha al agente automáticamente, y este completa la tarea por su cuenta. El gran cambio es que el trabajo rutinario pasa de una cola manual a un sistema que corre en segundo plano.

En este artículo te he guiado para crear dos automatizaciones: una revisión de código en PR y un monitor de cobertura programado. Son intencionadamente sencillas, pero te dan el punto de partida adecuado porque muestran cómo se comporta el sistema sin complejidad extra. Cuando te sientas cómodo, podrás implementar flujos avanzados.

La idea clave es empezar con una automatización acotada, escribir instrucciones como un runbook, ejecutarla en un modo de bajo riesgo y ampliar solo cuando se comporte de forma fiable. El valor viene menos de cuántas automatizaciones construyes y más de lo consistente que es cada una.

Para seguir construyendo sobre lo visto aquí, estos son los siguientes pasos recomendados:

• Profundiza en el modo Agent y el flujo de trabajo de Cursor con nuestro curso Software Development with Cursor.
• Descubre las novedades de Cursor 3.0.