Introducción

TaskGoblin ejecuta loops de ingeniería: un disparador más una instrucción, dentro de las herramientas que ya usas. Revisión de código, recogida de issues, mantenimiento nocturno — hecho sin que nadie tenga que acordarse de pedirlo.

Deja de escribir prompts a los agentes. Empieza a diseñar loops.

Esa diferencia es todo el producto. Un prompt te da una respuesta, una vez, y sólo si alguien se acuerda de escribirlo. Un loop es un disparador más una instrucción: se lanza solo, hace el trabajo en un sandbox aislado en la nube, abre un merge request que tú revisas, anota lo que aprendió y queda listo para el siguiente turno.

No abres una aplicación ni pegas código en un chat. Conectas las herramientas que tu equipo ya usa, y el trabajo empieza a ocurrir dentro de ellas.

Un loop es un disparador y una instrucción

  • El disparador es un evento — se abrió un pull request, se asignó un issue al goblin — o un horario, como cada día laborable a las 07:00.
  • La instrucción es lenguaje natural, no un DSL. "Revisa este merge request buscando errores de corrección y seguridad; señala problemas reales, no detalles de estilo." O: "Busca actualizaciones seguras de dependencias en acme/web y abre un merge request."

Todo lo que hace TaskGoblin es uno de estos. La revisión automática de código es un loop de evento sobre pull request abierto. Asignar un issue y recibir un merge request es un loop de evento sobre issue asignado. La salud nocturna de la suite de tests es un loop de horario a las 06:00. No hay una "función de automatización" aparte: los loops son la primitiva, y los comportamientos que parecen integrados son loops que te pertenecen y puedes reescribir.

Si sólo vas a leer una página más, que sea Loops.

Empiezas con loops ya en marcha

Inicia sesión con GitLab o GitHub y TaskGoblin aprovisiona tu organización, conecta tus repositorios e instala los loops por defecto de ese proveedor: revisar merge requests, recoger issues asignados. Abre un pull request y quedará revisado antes de que hayas configurado nada.

Esos loops por defecto son loops corrientes en tu página de Loops. Lee la instrucción, reescríbela con tus palabras, púsala, bórrala. Que el comportamiento sea tuyo es justamente el punto.

Cómo es un loop de verdad

Los loops se escriben en lenguaje natural. Aquí tienes uno real de la galería de plantillas — un guardián nocturno de tu suite de tests:

Disparador — todos los días a las 06:00

Instrucción — Clona acme/web y ejecuta la suite completa en la rama por defecto. Si algo falla y el arreglo es pequeño y seguro, abre un MR; si no, resume los fallos. Si todo pasa, no hagas nada.

Tres frases, y fíjate en todo lo que contienen: dónde trabajar, qué hacer, cuándo arreglar frente a cuándo escalar y — la línea más importante de cualquier instrucción desatendida — permiso para no hacer nada. Esa última cláusula es la razón de que recibas un merge request las mañanas en que algo se rompió, y silencio las mañanas en que no.

La galería trae nueve para empezar: actualizaciones de dependencias, docs desactualizados, entradas de changelog, limpiezas de deuda técnica, resúmenes de actividad, recordatorios de MRs estancados, avisos de triaje. Todas editables y tuyas en cuanto eliges una. Consulta Loops programados para verlas al detalle.

Por qué los loops corren en la nube

Como un goblin corre en un sandbox aislado en la nube y no en el portátil de alguien, el trabajo es:

  • Asíncrono — delega y cierra tu máquina.
  • Aislado — una frontera por organización, y tus credenciales se inyectan alrededor del agente, nunca se le entregan para que las lea.
  • Paralelo — cada ejecución tiene su propia rama y su propio sandbox, así que diez loops lanzándose a la vez son diez goblins trabajando, no una cola.
  • Siempre activo — el mantenimiento de las 03:00 y la revisión del pull request abierto a medianoche ocurren sin que nadie esté despierto.

Qué llega al final de un turno

Una rama y un merge request, revisados igual que los de un colega — o comentarios de revisión en línea, o una respuesta en el hilo de Slack donde preguntaste. Nunca un muro de texto que tengas que ejecutar tú, y nunca un commit a tu rama por defecto.

Por debajo hay un agente de código real (Claude Code, Codex o Gemini) con una copia de tu repositorio: lee archivos, ejecuta comandos y tests, y trabaja el problema como lo haría un colaborador. Como tiene identidad propia en cada herramienta — @taskgoblin en GitLab, Slack y Teams, taskgoblin[bot] en GitHub — todo el equipo puede delegarle trabajo y todo el equipo puede ver lo que hizo.

Adónde ir después

Empieza aquí

  • Guía rápida — del inicio de sesión a tu primer pull request revisado y tu primer loop programado.
  • Loops — la primitiva, y por qué gana a un prompt.

Construye tus loops

Entiende la maquinaria

Facturación