Automatizaciones
Cursor Automations ejecuta agentes en la nube en segundo plano, ya sea según una programación o en respuesta a eventos de GitHub, GitLab, Slack, webhooks, Linear y más.
Las automatizaciones permiten automatizar tareas como revisar commits recientes de PR en busca de errores, realizar revisiones exhaustivas para detectar vulnerabilidades, clasificar errores en Slack y resumir periódicamente los cambios en tu base de código.
Primeros pasos
Crea una nueva automatización en la ventana de agente de programación, en cursor.com/automations, con la habilidad /automate desde una sesión de agente local o a partir de una plantilla en Cursor Marketplace.
La habilidad /automate te permite describir en lenguaje natural el flujo de trabajo que quieres. Cursor configura por ti los desencadenantes, las instrucciones y las herramientas de la automatización.
Puedes hacerlo de cualquiera de estas formas:
- Elige un desencadenante, p. ej., cada hora o cuando se abra un pull request.
- Escribe una instrucción para la automatización.
- Elige las herramientas opcionales que el agente puede usar, como Send to Slack, Comment on Pull Request o herramientas de MCP.
- Elige si la automatización necesita un repositorio, varios repositorios o ninguno.
- Guarda y activa la automatización.
La página de automatizaciones también incluye tres agentes de programación gestionados por Cursor:
- Bugbot revisa los pull requests en busca de errores y problemas de calidad del código.
- agentes de seguridad revisan los pull requests y analizan las bases de código en busca de vulnerabilidades.
- Enrutamiento y aprobación de PR asigna los pull requests a revisores y puede aprobar cambios de bajo riesgo.
Facturación
Las automatizaciones crean agentes en la nube y se facturan según el consumo de estos. Consulta los precios de los agentes en la nube para obtener más información.
Las automatizaciones usan la ventana de contexto máxima compatible de cada modelo porque se ejecutan como agentes en la nube. No hay ningún selector para la ventana de contexto.
La facturación del consumo depende del alcance de permisos de la automatización:
- Del equipo: El consumo se factura al pool de consumo del equipo. Las automatizaciones se ejecutan con una cuenta de servicio compartida del equipo, por lo que no afectan al consumo de ningún usuario individual.
- Privado: El consumo se factura al usuario que creó la automatización.
- Visible para el equipo: El consumo se factura al usuario que creó la automatización, igual que en Privado.
Desencadenadores
Los desencadenadores determinan cuándo se ejecuta una automatización. Una automatización puede tener más de un desencadenador y se ejecutará cuando se active cualquiera de ellos.
Para ciertos desencadenadores, como Slack o programaciones cron, Cursor no usa ningún repositorio de forma predeterminada. Si tu automatización debe realizar cambios en el código, especifica en qué repositorio o repositorios deben trabajar los agentes de programación. Para los desencadenadores de control de código fuente, es obligatorio especificar uno o varios repositorios.
Desencadenadores programados
Los desencadenadores programados se ejecutan según una programación recurrente. Elige una opción predefinida o introduce una expresión cron para mayor precisión.
Los desencadenadores programados pueden ejecutarse con retraso, pero no se iniciarán antes de la hora indicada.
Desencadenadores del control de código fuente
Los desencadenadores del control de código fuente responden a eventos de pull request y push de tu proveedor de Git conectado: GitHub, GitLab y Bitbucket Cloud. Conecta la automatización a un repositorio o a un entorno multi-repo.
Todos los proveedores conectados admiten los desencadenadores principales de pull request y push:
- Borrador abierto - Cuando se crea un pull request en borrador.
- Pull request abierto - Cuando se crea un PR que no es un borrador o un borrador se marca como listo para revisión.
- Push a un pull request - Cuando se envían nuevos commits a un PR existente.
- Pull request fusionado - Cuando se fusiona un PR.
- Push a una rama - Cuando se envían commits a una rama específica fuera de un pull request.
- Comentario añadido - Cuando alguien deja un comentario de nivel superior en un pull request.
GitHub admite la mayor cantidad de desencadenadores. GitLab y Bitbucket admiten los desencadenadores principales anteriores, además de algunos adicionales que se enumeran en sus secciones a continuación.
Desencadenadores de GitHub
GitHub es el proveedor de referencia y es compatible con todos los desencadenadores de control de código fuente. Además de los desencadenadores principales, añade:
- Etiqueta de pull request modificada - Cuando se añade o elimina una etiqueta específica, o cualquier etiqueta, de un pull request.
- Etiqueta de problema modificada - Cuando se añade o elimina una etiqueta de un problema que no es un PR.
- CI completada - Cuando finaliza una comprobación de GitHub en un pull request o rama.
- Comentario de problema - Cuando se publica un comentario en un problema que no es un PR.
- Comentario de revisión de PR - Cuando se deja un comentario en línea en un diff de pull request.
- Revisión de PR enviada - Cuando se envía una revisión como aprobada, con cambios solicitados o con comentarios.
- Hilo de revisión actualizado - Cuando un hilo de revisión en un pull request se marca como resuelto o no resuelto.
- Ejecución de flujo de trabajo completada - Cuando finaliza una ejecución de flujo de trabajo de GitHub Actions en un pull request o rama.
El Cursor Marketplace incluye plantillas para clasificar fallos de GitHub Actions y corregir comentarios de revisión de pull request.
Desencadenadores de GitLab
Además de los desencadenadores principales, GitLab añade:
- Cambio de etiqueta en pull request - Cuando se añade o elimina una etiqueta de una solicitud de fusión.
- Pull request aprobado - Cuando se aprueba una solicitud de fusión.
Desencadenadores de Bitbucket
La compatibilidad con Bitbucket se limita a Bitbucket Cloud (bitbucket.org). Bitbucket Server y Data Center no son compatibles. Además de los desencadenadores principales, incluye:
- Pull request aprobado - Cuando se aprueba un pull request.
Bitbucket Cloud no cuenta con desencadenadores para etiquetas de pull request ni comentarios de revisión en línea.
Los desencadenadores de pull request no se ejecutan en PR abiertos desde forks. Estas ejecuciones fallan con el error "Fork pull requests not supported" porque la rama solo existe en el fork y no es seguro ejecutar código externo con los permisos del repo. La excepción son los desencadenadores Pull request fusionado, que sí se ejecutan porque parten del commit de fusión. Para evitar esta limitación, envía la rama al propio repo y abre el PR desde allí.
Desencadenadores de Slack
Los desencadenadores de Slack responden a eventos de la integración de Slack de Cursor.
Por el momento, los desencadenadores de Slack solo pueden acceder a los canales públicos de Slack.
- Nuevo mensaje en un canal - Cuando se envía un mensaje a un canal de Slack conectado. Sin un filtro de mensajes, el desencadenador solo se activa con mensajes de nivel superior del canal. Añade un filtro de palabra clave o una expresión regular si también quieres ejecutar automatizaciones a partir de respuestas en hilos.
- Reacción con emoji - Cuando alguien reacciona a un mensaje de Slack con un emoji específico.
- Canal creado - Cuando se crea un nuevo canal público de Slack en tu espacio de trabajo.
Desencadenadores de webhooks
Los desencadenadores de webhooks crean un endpoint HTTP privado para tu automatización. Envía una solicitud POST al endpoint para iniciar una ejecución. Puedes usar webhooks para conectar automatizaciones con sistemas internos, canalizaciones de CI, herramientas de monitorización y más.
Para obtener la URL del webhook, primero debes guardar la automatización. Al hacerlo, se generarán una URL de webhook a la que llamar y una clave de API para la autenticación.
Desencadenadores de Linear
Los desencadenadores de Linear responden a eventos de la integración de Cursor con Linear.
- Problema creado - Cuando se crea un nuevo problema.
- Estado cambiado - Cuando cambia el estado de un problema.
- Fin del ciclo - Cuando finaliza un ciclo de Linear.
Desencadenadores de Sentry
Los desencadenadores de Sentry se ejecutan cuando se producen eventos de errores y problemas en tu proyecto de Sentry. Úsalos para investigar errores automáticamente, identificar las causas raíz y proponer soluciones. Consulta la plantilla del marketplace Investigate Sentry issues para ver un ejemplo listo para usar.
- Problema creado - Cuando se crea un problema nuevo en Sentry.
- Problema actualizado - Cuando cambia un problema existente, como al actualizar su estado o asignación.
- Cualquier evento de problema - Coincide con todos los tipos de eventos de problemas.
Desencadenadores de PagerDuty
Los desencadenadores de PagerDuty se ejecutan ante eventos de incidentes y pueden ayudar a clasificar o incluso resolver incidentes automáticamente.
- Incidente activado - Cuando se crea un nuevo incidente.
- Incidente confirmado - Cuando se confirma un incidente.
- Incidente resuelto - Cuando se resuelve un incidente.
- Cualquier evento de incidente - Coincide con todos los tipos de eventos de incidentes.
Herramientas
Cursor Automations puede habilitar herramientas para ofrecer capacidades más avanzadas relacionadas con GitHub, Slack, la memoria, MCP y más. Las automatizaciones también incluyen el mismo conjunto básico de herramientas que otros agentes en la nube. Consulta Capacidades del agente en la nube para obtener más información.
Creación de pull requests
Las automatizaciones basadas en repositorios pueden abrir pull requests después de realizar los cambios de código solicitados en la instrucción de automatización. Esta herramienta está activada de forma predeterminada en todas las automatizaciones.
El pull request se abre en los repositorios especificados para el desencadenante de control de código fuente. Para otros desencadenantes, se usan los repositorios especificados por el entorno.
Comentar en una pull request
Publica comentarios en una pull request de destino. Admite comentarios de revisión generales y comentarios de código en línea.
Si activas las aprobaciones, el agente también puede aprobar, solicitar cambios y descartar revisiones. De lo contrario, solo puede publicar comentarios.
Solicitar revisores
Solicita revisores para un pull request específico. El agente puede usar git, la memoria y otras herramientas para identificar expertos en el dominio.
Enviar a Slack
Envía mensajes a un canal de Slack. Puedes seleccionar un canal específico o dejar que el agente elija dinámicamente cualquier canal.
Al permitir cualquier canal, Cursor también incluye el acceso de lectura necesario para que el agente descubra los canales públicos disponibles.
Ten en cuenta que el agente recibe acceso de lectura a los canales públicos a los que puede enviar mensajes.
Leer canales de Slack
Otorga al agente acceso de solo lectura para consultar y leer mensajes de canales públicos de Slack.
Úsalo cuando el agente necesite más contexto antes de responder o abrir un pull request.
Servidor MCP
Conecta un servidor MCP (Model Context Protocol) para que el agente pueda usar herramientas externas y fuentes de datos.
Al conectar un servidor MCP, el agente obtiene acceso a todas las herramientas que expone ese servidor. Conecta únicamente servidores de confianza con los permisos que necesita tu automatización.
Memorias
Las memorias permiten al agente leer y escribir notas persistentes entre ejecuciones de la misma automatización. Úsalas para crear agentes que recuerden y mejoren con el tiempo. Cada memoria se almacena como una entrada con nombre (MEMORIES.md de forma predeterminada) fuera del sistema de archivos de trabajo del agente.
Las memorias están activadas de forma predeterminada, pero pueden desactivarse. Se pueden consultar y editar desde la interfaz de configuración de herramientas.
Los agentes pueden eliminar archivos de memoria obsoletos durante las ejecuciones de automatización. También puedes eliminar archivos de memoria desde la interfaz de configuración de herramientas.
Las memorias persisten entre ejecuciones y deben usarse con precaución si tu automatización procesa entradas no confiables. Las entradas pueden generar memorias engañosas o maliciosas que afecten involuntariamente a futuras ejecuciones de automatización.
Uso de la computadora
El uso de la computadora permite que los agentes en la nube iniciados mediante automatizaciones usen una computadora como lo haría un desarrollador. Esto significa que las automatizaciones pueden controlar un navegador, generar capturas de pantalla o grabaciones, o usar tus servicios internos. Se incluye de forma predeterminada en todas las automatizaciones.
Para que el uso de la computadora sea efectivo, asegúrate de haber configurado un entorno de desarrollo para tu automatización. Luego, puedes solicitar una demostración en las instrucciones de la automatización cuando quieras que el agente muestre su trabajo. Por ejemplo, indícale al agente que incluya una breve grabación de pantalla después de modificar un flujo de cara al usuario.
Ajustes de automatización
Modelo
Puedes seleccionar qué modelo usará el agente en la nube para tu automatización.
Repositorios
Elige si la automatización no necesita repositorio, necesita uno o requiere un entorno multirrepositorio.
La configuración del repositorio controla el contexto de la base de código de cada ejecución:
- Sin repositorio: El agente no clona código. Usa esta opción para flujos de trabajo que solo necesitan Slack, MCP, webhooks, Linear o PagerDuty. No puede editar código ni abrir pull requests.
- Un solo repositorio: El agente trabaja en un repositorio y una rama. Usa esta opción cuando la automatización deba leer, revisar o modificar código en una base de código.
- Entorno multirrepositorio: El agente trabaja en los repositorios de un entorno. Usa esta opción cuando la tarea abarque varias bases de código.
Para ciertos desencadenadores, como Slack o programaciones cron, Cursor no usa un repositorio de forma predeterminada. Si tu automatización debe realizar cambios de código, especifica en qué repositorio o repositorios deben trabajar los agentes.
Para los desencadenadores del control de código fuente, es obligatorio especificar uno o varios repositorios.
Automatizaciones de un solo repositorio
De forma predeterminada, una automatización se ejecuta en un repositorio y una rama. Es la opción adecuada cuando el agente debe leer, revisar o modificar código en una sola base de código.
Los desencadenadores del control de código fuente identifican el repositorio a partir del pull request. Para otros desencadenadores, elige el repositorio y la rama en los ajustes de la automatización.
Automatizaciones multirrepositorio
Usa un entorno multirrepositorio cuando una automatización deba trabajar en varios repositorios. Selecciona varios repositorios al configurar el entorno o elige uno existente en tu panel de control de agentes en la nube.
Permisos
Controla quién puede consultar y gestionar la automatización. El alcance de permisos también determina cómo se factura el consumo.
- Privada: Solo tú puedes gestionar la automatización. Los administradores del equipo pueden consultarla y desactivarla.
- Visible para el equipo: Solo tú puedes gestionar la automatización. Los miembros del equipo pueden consultarla y los administradores del equipo pueden desactivarla. Sigue ejecutándose con tu autenticación.
- Del equipo: Los miembros del equipo pueden consultar la automatización. Solo los administradores del equipo pueden gestionarla. Se ejecuta con la cuenta de servicio compartida del equipo para automatizaciones.
Promover una automatización de Privada o Visible para el equipo a Del equipo cambia la identidad con la que se ejecuta. Deja de usar tu autenticación y empieza a usar la cuenta de servicio compartida del equipo para automatizaciones. Si la automatización usa desencadenadores de webhook, vuelve a generar su clave de API de webhook tras el cambio de alcance. Si usa MCP u otras integraciones que dependen de credenciales personales de OAuth, asegúrate de que estén configuradas para la cuenta de servicio del equipo. Solo los administradores del equipo pueden promover una automatización a Del equipo.
Identidad
Cuando una automatización interactúa con servicios externos, utiliza las siguientes identidades:
- Los comentarios de GitHub, las aprobaciones de revisión y las solicitudes de revisores se realizan como
cursor. - Las automatizaciones con ámbito de equipo abren pull requests como
cursor. - Las automatizaciones privadas abren pull requests con tu cuenta de GitHub.
- Los mensajes de Slack se envían como el bot de Cursor.
Redacción de instrucciones
Las instrucciones definen lo que debe hacer el agente. Escríbelas igual que escribirías instrucciones para una ejecución de un agente en la nube.
Consejos:
- Especifica qué debe comprobar, cambiar o generar el agente.
- Haz referencia a las acciones que activaste; puedes mencionar herramientas con @ o nombrarlas informalmente.
- Incluye reglas de decisión para distintos casos.
- Establece un criterio de calidad para determinar cuándo el agente debe abrir un pull request, comentar o no hacer nada.
- Describe el formato de salida que deseas.