La mayoría de las herramientas de IA para código giran en torno a un prompt. Describes lo que quieres, un agente responde y el intercambio termina. Eso funciona hasta el momento en que lo valioso deja de ser una buena respuesta y pasa a ser el mismo trabajo ocurriendo de forma fiable, siempre, sin que nadie tenga que acordarse de pedirlo.
TaskGoblin está construido alrededor de un loop.
Un loop es un disparador y una instrucción
Esa es toda la primitiva.
- Un disparador decide cuándo despiertan los goblins. Es un evento — se abrió un pull request, se asignó un issue al goblin — o un horario: cada día laborable a las 07:00.
- Una instrucción es texto libre que describe qué hacer entonces. "Revisa este merge request buscando corrección y seguridad; ignora los detalles de estilo que ya detecta un linter." "Actualiza dependencias seguras de parche y menores, ejecuta los tests y abre un MR por ecosistema."
Junta las dos y ya no tienes una petición: tienes una capacidad permanente. Nadie tiene que estar delante del teclado y nadie tiene que acordarse.
Todo es un loop
Esto no es una funcionalidad al lado del producto: es el producto. Los comportamientos que darías por sentado como magia interna son loops corrientes:
| Lo que se ve desde fuera | El loop que hay debajo |
|---|---|
| Cada pull request se revisa | Un loop de evento en pull request abierto |
| Asignas un issue y recibes un merge request | Un loop de evento en issue asignado |
| Las dependencias se mantienen al día sin ticket | Un loop programado cada lunes a las 08:00 |
| La documentación nunca se desfasa del código | Un loop programado cada miércoles |
| Un resumen de lo que se movió llega a Slack cada mañana | Un loop programado a las 09:00 |
Al conectar GitLab o GitHub, TaskGoblin te instala un conjunto inicial — por eso la revisión de código empieza a funcionar antes de que hayas configurado nada. No son especiales: ábrelos, lee la instrucción, reescríbela con tus palabras, púsalos o bórralos.
Un turno de un loop
Cada turno funciona igual, lo dispare un webhook o un reloj, sea el primero o el quinientos:
- Se lanza. El disparador coincide. TaskGoblin abre — o reutiliza — un hilo para ese trabajo.
- Contexto. El goblin lee el issue, el hilo, el diff, las convenciones de tu organización y las notas que dejaron los goblins anteriores, antes de tocar nada.
- Trabajo. Se ejecuta dentro de un sandbox aislado en la nube con una copia de tu repositorio: lee archivos, los edita, ejecuta comandos y tests.
- Entrega. Abre un merge request, deja comentarios de revisión en línea o responde en el hilo — donde corresponda.
- Traspaso. Anota lo aprendido y lo que queda abierto, para que el siguiente turno empiece ahí y no desde cero.
El paso 5 es lo que separa un loop de un cron. Cada turno está informado por los anteriores: un loop que corre todas las semanas durante un año no es el mismo loop cien veces, es uno que ha estado prestando atención.
Por qué un loop gana a un prompt
- Corre sin ti. El trabajo ya está hecho cuando miras, en vez de esperar a que alguien note que hacía falta.
- Es revisable. Cada turno termina en una rama y un merge request, revisados como los de un colega. Nada se fusiona solo.
- Se acumula. Corrige a un goblin una vez y la corrección queda escrita para todos los siguientes.
- Tiene interruptor. Un loop es una fila que te pertenece. Púsalo y el comportamiento se detiene al instante.
Dónde viven los loops
Gestiónalos desde el área Loops de tu organización (/{organisation}/loops). Cada loop tiene su página: la instrucción, el disparador, un interruptor de Activo y el historial de sus ejecuciones recientes, para que veas lo que hizo en vez de confiar en que se lanzó.
Los goblins también pueden crear loops por su cuenta durante una ejecución. Uno que note que le pides lo mismo cada viernes puede proponer el loop que elimina la petición.
Adónde ir después
- Loops de evento — loops que se lanzan con un pull request, un issue asignado o una etiqueta, y los que ya tienes.
- Loops programados — loops por horario, y las plantillas desde las que partir.
- Ejecuciones puntuales — las peticiones directas que no son loops, y cómo saber cuándo una quiere serlo.
- Cómo funciona una ejecución — qué ocurre dentro de un solo turno.