📝 El prompt que inicia el loop
El punto de partida de cualquier task runner es el prompt que carga la capability de loop de Claude Code. Con una sola línea, el agente sabe cómo montar el sistema de loop, iterar sobre tareas y programarse automáticamente.
📋 Prompt listo (copia y úsalo)
Load the loop skill, work through plan.md one task at a timeEste prompt hace tres cosas: carga la "loop skill" (capacidad nativa de Claude Code), señala el archivo plan.md como fuente de tareas e indica al agente que procese una tarea por ciclo.
"Sé que este es un ejemplo muy, muy básico, pero quiero mantenerlo simple a propósito. El sistema escribió el prompt: /loop work through plan.md one task at a time."
⚙ Qué sucede internamente
Claude Code carga el skill de loop como primera acción: "it loads the loop skill as the very first thing"
Identifica que plan.md contiene una lista secuencial de tareas
Configura /loop automáticamente y programa el primer wake-up
El agente escribe por sí solo el prompt del loop: "/loop work through plan.md one task at a time"
📋 Plantilla de plan.md
El plan.md es el contrato entre tú y el loop. Cada tarea debe estar específica, verificable e independiente. Las tareas vagas generan resultados vagos. Las tareas interdependientes rompen el aislamiento del loop.
📄 Plantilla (copia y adapta)
# Plan - [Nome do Projeto]
## Tasks
- [ ] **Task 1: Setup inicial**
Criar a estrutura de diretorios e arquivos base.
Criterio: diretorios existem, arquivos criados sem erros.
- [ ] **Task 2: Implementar componente X**
Criar o componente principal com props tipadas.
Criterio: componente renderiza sem erros, tipos corretos.
- [ ] **Task 3: Adicionar estilos**
Aplicar Tailwind CSS seguindo o design system.
Criterio: visual consistente, responsivo em mobile.
- [ ] **Task 4: Escrever testes**
Testes unitarios para cada funcao publica.
Criterio: todos os testes passam, coverage > 80%.
- [ ] **Task 5: Documentacao**
README com instrucoes de uso e exemplos.
Criterio: novo dev consegue rodar seguindo o README.✓ Buenas prácticas
- ✓Una tarea por checkbox
- ✓Criterio de aceptación explícito
- ✓Tareas independientes entre sí
- ✓Orden lógico de ejecución
✗ Anti-patterns
- ✗"Hacer que la app funcione" (demasiado vago)
- ✗10+ tareas (fragmentación excesiva)
- ✗Tareas que dependen de una entrada externa
- ✗Sin criterio de "done"
🔍 Monitoreo del progreso
Después de iniciar el loop, el agente trabaja de forma autónoma. Cada ciclo sigue el mismo patrón: despertar, verificar la siguiente tarea, ejecutarla, validarla y programar el próximo wake-up. Puedes seguirlo directamente en la terminal.
"Dice que esta es una lista secuencial de tareas: va a hacer la primera tarea y luego programará una activación rápida. Así que configura /loop por su cuenta."
📊 El ciclo de un wake-up
Wake-up
El /loop despierta al agente con el prompt que él mismo escribió
Verificar plan.md
Lee el archivo e identifica la próxima tarea sin marcar
Ejecutar tarea
Implementa, genera archivos y ejecuta los comandos necesarios
Validar y marcar
Verifica el criterio de aceptación, marca [x] en plan.md, programa el próximo wake-up
"Está reanudando con una activación de /loop. Y mira eso. Yo no escribí este prompt para nada."
⚙ Configuración de condiciones de salida
Un loop sin exit condition es el error más costoso que puedes cometer. El agente se ejecutará indefinidamente, gastando tokens sin llegar a un resultado. Define siempre cuándo debe detenerse el loop.
🛑 Tres formas de detenerse
1. Finalización natural
Todas las tareas del plan.md marcadas como [x].
/goal All tasks in plan.md are checked off2. Max iterations
Red de seguridad: detente después de N ciclos, independientemente del estado.
/loop --max-iterations 10 work through plan.md one task at a time3. Condición de falla
Si una tarea falla 3 veces, detente e informa.
If a task fails validation 3 times, stop the loop and report what went wrong.🎯 Punto de reflexión
La condición de salida más segura es la combinación de /goal (finalización natural) + max iterations (red de seguridad). Así, si algo sale mal y el agente no logra completar la tarea, se detiene en vez de consumir tokens indefinidamente.
🔄 Variaciones del prompt
El prompt básico funciona para listas de tareas simples, pero los distintos escenarios requieren variaciones. Aquí tienes prompts adaptados a los casos de uso más comunes.
Load the loop skill. Work through refactor-plan.md one file at a time.
For each file: refactor, run tests, commit if green. Skip if tests fail after 2 retries.Ideal para la refactorización incremental con una red de seguridad de pruebas.
Load the loop skill. Work through migration-plan.md one step at a time.
After each step, validate by running the app and checking for errors.
Never proceed to the next step if the current one has errors.Para migraciones de versión o de framework con validación rigurosa.
Load the loop skill. Work through docs-plan.md one section at a time.
For each section: read the source code, write documentation, include code examples.
Mark the task done when the doc file is created and has at least 200 words.Generación de documentación a partir del código fuente.
❓ Preguntas
Antes de empezar a usar el task runner para todo, vale la pena plantear las preguntas que el propio Cole Medin propone sobre el enfoque básico.
¿El loop simple escala?
Para 5 tareas, funciona. Para 50, la ventana de contexto va a explotar. Cole Medin observa que "if you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it." El task runner simple tiene un límite natural de escalabilidad.
Calidad vs. velocidad
El loop se ejecuta rápido, pero sin revisión humana entre tareas. Para pruebas de concepto y exploración, es aceptable. Para código de producción, Cole es directo: "there is no way you're gonna convince me that loop engineering is the way to get the best results possible."
Costo de un loop básico
Hasta el loop más simple acumula tokens rápidamente. Cada activación vuelve a cargar el contexto. Para 5 tareas con validación, espera gastar entre 50k y 200k tokens, según la complejidad.
🎯 Punto de reflexión
El task runner es la puerta de entrada. Empieza aquí, entiende el mecanismo y, cuando necesites más control, pasa al módulo 4.2 (orchestrator + workers). La progresión es deliberada: primero lo simple, lo complejo cuando sea necesario.
📋 Resumen del módulo
Módulo siguiente:
4.2 -- Ciclo intermedio: GitHub Issue Bot (orquestador + workers paralelos)