Un loop de evento se lanza cuando ocurre algo en una herramienta que has conectado. Sin horario, sin ritual de asignación, sin que nadie escriba un prompt: se abre un pull request y la revisión ya está en marcha antes de que nadie haya cambiado de pestaña.
Su instrucción es una guía permanente que se superpone a lo que el evento ya trae. Al goblin se le entrega automáticamente el merge request o el issue como contexto; tu instrucción le dice qué quieres tú que haga con ello.
Los eventos sobre los que puedes crear un loop
| Evento | Origen | Se lanza cuando |
|---|---|---|
| Merge request abierto | GitLab | Se abre, reabre o actualiza un MR con nuevos commits |
| Issue asignado | GitLab | Se asigna un issue al bot @taskgoblin |
| Pull request abierto | GitHub | Se abre, reabre o actualiza un PR con nuevos commits |
| Issue etiquetado | GitHub | Se añade la etiqueta taskgoblin a un issue |
| Issue asignado | Linear | Se asigna un issue al agente TaskGoblin |
| Issue asignado | Jira | Se asigna un issue a la cuenta de TaskGoblin |
Como los eventos de "apertura" cubren también las actualizaciones, un loop de revisión reconcilia en lugar de repetirse: en una segunda pasada lee los hallazgos que dejó antes, resuelve los que ya has corregido y sólo publica lo que es realmente nuevo.
Los loops que ya tienes
No empiezas con una página en blanco. En cuanto un proveedor existe para tu organización, TaskGoblin instala sus loops por defecto:
- GitLab — Revisar merge requests y Trabajar en issues asignados.
- GitHub — Revisar pull requests y Trabajar en issues etiquetados.
- Linear — Trabajar en issues asignados.
- Jira — Trabajar en issues asignados.
Reproducen lo que la gente espera de un agente de código recién sacado de la caja. La diferencia es que son tuyos: loops reales en tu página de Loops, con instrucciones que puedes leer y cambiar.
La instalación ocurre una sola vez, para siempre. Si borras un loop por defecto, se queda borrado — reconectar el proveedor no lo resucita en silencio.
Reescribir la instrucción es justamente el punto
La instrucción de revisión por defecto pide corrección, seguridad y mantenibilidad, y le dice al goblin que se calle cuando el cambio es sólido. Es una posición de partida razonable, no una política que tengas que aguantar. Los equipos suelen estrecharla o ampliarla:
- "Señala sólo problemas de seguridad y riesgos de pérdida de datos. Nada más."
- "Sé estricto con la cobertura de tests: todo cambio de comportamiento necesita un test; dilo si falta."
- "Comprueba además que cualquier endpoint nuevo pase por nuestro middleware de rate limiting."
La instrucción es texto libre, así que puede codificar lo que un linter no puede: vuestras convenciones, vuestros incidentes pasados, el error que este equipo repite una y otra vez.
La instrucción por defecto, y una versión endurecida
Esto es lo que viene de serie:
Revisa este merge request. Céntrate en corrección, seguridad y mantenibilidad — señala problemas reales, no detalles de estilo que ya detectaría un linter. Deja comentarios en línea sólo donde aporten valor, mantenlos concretos y accionables, y quédate callado cuando el cambio sea sólido.
Es deliberadamente contenida, porque a un revisor que comenta todo se le acaba silenciando. Y esto es el mismo loop después de que un equipo haya convivido con él un mes y haya tenido un incidente:
Revisa este merge request buscando corrección, seguridad y mantenibilidad. Señala problemas reales, no detalles de estilo.
Además, comprueba siempre: que todo cambio de comportamiento tenga un test; que ningún endpoint nuevo salga sin nuestro middleware de rate limiting; que ninguna migración modifique una migración existente; que no se registre el cuerpo completo de una petición. Marca esto como crítico aunque el resto del cambio esté bien.
Si el MR supera las 400 líneas, dilo en el resumen y revisa primero los archivos de más riesgo en vez de sobrevolarlo todo. Quédate callado cuando el cambio sea sólido.
Nada de la segunda versión es exótico: es conocimiento institucional que antes vivía en una wiki que nadie abría, ahora pegado al momento en que importa. Ésa es la diferencia entre un loop que heredaste y un loop que es tuyo.
El interruptor
Esta parte merece leerse dos veces, porque explica un comportamiento que si no parecería un fallo.
Un evento sujeto a loop que no encuentra ningún loop activo no lanza nada. Pausa tu loop de revisión y los merge requests dejan de revisarse. Bórralo y lo mismo. TaskGoblin sigue aceptando el webhook: simplemente no tiene ninguna instrucción permanente sobre la que actuar, así que ningún goblin despierta y no se factura nada.
Ése es el precio de que el comportamiento sea tuyo en vez de algo que te hacen. Si la revisión automática ha dejado de ocurrir, lo primero que hay que mirar es si su loop sigue activo.
Lo que nunca está sujeto a loop
Las peticiones humanas explícitas siempre se ejecutan, exista o no un loop:
@taskgoblinmencionado en un merge request, pull request o comentario de issue- Un mensaje o mención en Slack o Microsoft Teams
- Un comentario de seguimiento en un issue de Linear que el goblin ya está trabajando
- Una mención en un comentario de un issue de Jira
- Responder
@taskgoblin fixa uno de sus propios comentarios de revisión
Si una persona ha pedido algo directamente, un goblin responde. Los loops gobiernan el trabajo no solicitado, y sólo ése.
Cuando coinciden varios loops
Nada te impide tener más de un loop sobre el mismo evento — uno de revisión general y otro más estricto para seguridad, por ejemplo. Cuando un evento coincide con varios, se le muestran al goblin todas las instrucciones candidatas y él juzga cuál aplica, dejando registrada su elección para que el historial siga siendo honesto. El trabajo sigue ocurriendo en una sola ejecución: los loops no se multiplican en revisiones duplicadas sobre un mismo merge request.
Adónde ir después
- Loops programados — el otro tipo de disparador, para el trabajo que ningún evento anuncia.
- Conecta tus integraciones — sobre qué proveedores puedes crear loops y qué desbloquea cada uno.
- Ejecuciones puntuales — las peticiones directas que se saltan los loops por completo.