Cada turno de un loop funciona igual, lo dispare un webhook, un reloj, o alguien mencionando al goblin directamente. Esta página cuenta qué ocurre entre ese disparo y el merge request.
1. Llega el disparador
TaskGoblin encuentra o crea el hilo de ese trabajo — la conversación de un issue, un merge request o un loop — y registra el turno como un mensaje dentro de él. Un seguimiento sobre trabajo ya en marcha se une al hilo existente en vez de abrir uno nuevo: por eso el goblin nunca te pide que vuelvas a explicarte.
2. Se levanta el sandbox
La ejecución recibe un contenedor aislado en la nube con una copia de tu repositorio. Los sandboxes son persistentes y se reutilizan entre turnos del mismo hilo, así que un seguimiento aterriza en un entorno que ya tiene el repositorio y el estado del turno anterior — el goblin retoma en vez de partir de una caja vacía.
A menudo vienen precalentados, y por eso una ejecución suele empezar a trabajar en segundos en lugar de esperar a un contenedor frío. El sandbox en la nube cubre en detalle el aislamiento, la persistencia y el autoalojamiento.
3. Lee antes de escribir
Antes de tocar código, el goblin reúne contexto: el issue o el diff que lo disparó, el historial del hilo, la nota de traspaso que dejó el goblin anterior y las convenciones de tu organización. En un loop de evento, tu instrucción permanente se superpone al contexto del propio evento.
Éste es el paso que separa un cambio útil de uno meramente plausible. Un agente que ve cómo se revisó el cambio anterior, y por qué se revirtió un enfoque previo, decide mejor que uno que empieza en una habitación vacía.
4. Un agente de código real hace el trabajo
Dentro del sandbox corre un agente de código de verdad — Claude Code, Codex o Gemini, según la cuenta de modelo de esa ejecución. Tiene las herramientas de un desarrollador: lee y edita archivos, ejecuta comandos y lanza tus tests. No está autocompletando un diff, está trabajando el problema.
5. Rama, commit, push, merge request
El goblin sigue el flujo de trabajo que ya usa tu equipo:
- Trabaja en una rama dedicada —
142-taskgoblinpara el issue 142 en GitLab o GitHub,proj-123-taskgoblinpara una clave de Jira — nunca en tu rama por defecto. - Hace commit firmando su trabajo para que el rastro sea legible, y sube la rama.
- Abre un merge request (GitLab) o pull request (GitHub) y reporta el enlace donde empezó el trabajo.
La excepción es una ejecución disparada sobre un merge request existente: entonces empuja a la rama de ese MR en vez de abrir una rama rival.
Como la salida es una rama y un merge request, revisar es exactamente lo que ya es para las contribuciones humanas. Nada se fusiona sin tu visto bueno.
6. Reporta donde ya estás mirando
Durante la ejecución, el goblin responde a través de la superficie a la que pertenece el trabajo: actividad en un issue de Linear, comentarios en línea en un merge request, una tarjeta que se actualiza sola en Slack o Teams. No miras una terminal, y no hay un panel aparte que tengas que acordarte de abrir.
7. Anota lo que pasó
Lo último que hace un goblin — después de enviar la respuesta, nunca antes — es registrar una nota de traspaso: qué aprendió, qué decidió, qué queda abierto. El siguiente turno la lee primero.
Por eso un loop se acumula en vez de repetirse. Ver El cerebro.
Los secretos no entran en el agente
El goblin nunca ve tus credenciales. El acceso git dentro del sandbox se aprovisiona por organización en tiempo de ejecución — un token OAuth de GitLab o un token de instalación de GitHub recién emitido — y se inyecta en el entorno alrededor del agente en lugar de entregársele como algo que leer. Puede usar el acceso que necesita para clonar y empujar sin que tus secretos entren nunca en su contexto ni en su transcripción.
Ese token es sólo para el transporte git. Los comentarios, revisiones y actualizaciones de issues pasan por las integraciones propias de TaskGoblin, para que se publiquen como el goblin y no como tú.
Cuando algo sale mal
Una ejecución fallida no desaparece. El goblin lo reporta con claridad en la superficie desde la que lo disparaste, el fallo queda registrado en la ejecución, y la nota de traspaso arrastra el muro con el que chocó para que el siguiente turno no lo redescubra. Una ejecución que nunca llegó a tener sandbox — bloqueada por saldo agotado, por ejemplo — nunca se factura.
Adónde ir después
- El sandbox en la nube — aislamiento, persistencia y ejecución en tu propia infraestructura.
- El cerebro — el conocimiento escrito que lleva el trabajo hacia adelante.
- Precios y créditos — cuánto cuesta un turno, medido por segundo.