Automatizaciones: los agentes se ponen manos a la obra cuando pasa algo

Las reglas viven en la pestaña Details → Automation → Automations del proyecto; la vista Runs muestra el historial de cada regla.

• CI en rojo: falla una ejecución en GitHub Actions, GitLab CI o Jenkins, según lo conectado en la pestaña CI/CD. Límitalo con patrones de rama como “main, release/*”.
• Comentario en un PR: solo cuentan los comentarios de propietarios, miembros y colaboradores del repositorio, nunca de bots. Si un agente ya trabaja en ese PR, los comentarios nuevos le llegan a él.
• Incidencia etiquetada: la etiqueta por defecto es “ajan”. La etiqueta tiene que ponerla una persona con permiso de escritura.
• Programado: una expresión cron de 5 campos en hora local, por ejemplo los días laborables a las 09:00.

Cuando salta una regla, un agente de Claude Code o Codex se abre en su propio worktree, en una rama ajan/…, y sigue el playbook que elegiste. Una regla también puede iniciar un flujo desde su nodo Start o preparar un plan de equipo en paralelo que espera tu aprobación. El ajuste de entrega decide adónde va el resultado.

• Automatic: hace push a la rama cuyo CI falló o a la rama del PR; si no, abre un PR; nunca hace push directo a la rama por defecto.
• Abrir un PR, hacer push a la misma rama, añadir a la cola de fusión o dejarlo en la rama.
• Mientras un proyecto no tiene reglas, se ofrecen cuatro ya preparadas: arreglar el CI cuando falla, atender los comentarios de PR, resolver las incidencias etiquetadas “ajan” y actualizar dependencias los lunes.

Un playbook es la instrucción que le dice al agente cómo hacer el trabajo. Hay seis integrados: corregir un bug, corregir un fallo de CI, atender comentarios de PR, construir una función a partir de una incidencia, actualizar dependencias (solo minor y patch) y subir la cobertura de tests. Guarda tus propios playbooks en este ordenador o en el repositorio como archivos .agentvera/playbooks/*.md, que llegan a tu equipo a través de git.

Como las automatizaciones corren solas, los límites se fijan de antemano.

• Cada regla se ejecuta como máximo de 1 a 50 veces en 24 horas móviles, 5 por defecto.
• Como máximo 2 correcciones automáticas por rama y día, y solo una a la vez.
• GitHub se consulta cada 2 minutos; se omiten las ejecuciones de CI y los PR de forks.
• El texto de comentarios e incidencias se pasa al agente marcado como no fiable, fuera del texto que solo describe el trabajo.
• Antes de un push se comprueba que los commits no incluyan archivos .env, claves, .npmrc ni credenciales; si se encuentra alguno, no se sube nada.