Cómo crear bucles con Claude Code

La mayoría de los flujos de trabajo con Claude siguen siendo de un solo uso.

Escribes un prompt. Claude responde. La sesión termina. Mañana empiezas desde cero.

Eso está bien para tareas puntuales.

Pero para trabajos repetitivos — revisiones diarias, clasificación de CI, monitoreo de proyectos, seguimiento de reuniones — estás reconstruyendo el mismo contexto cada día.

Eso no es un flujo de trabajo. Es trabajo manual con un toque de IA.

La mejor abstracción es un bucle.

Guarda esto. Te será útil.

Qué es realmente un bucle de Claude

Un bucle no es "solo preguntarle a Claude otra vez".

Un bucle es una estructura de flujo de trabajo repetible alrededor del modelo.

Define:

→ Qué desencadena la ejecución

→ Qué contexto lee Claude antes de actuar

→ Qué se le permite hacer a Claude → Cómo se verifica el resultado

→ Dónde se almacena el estado

→ Cuándo detenerse, repetir o solicitar revisión humana

El modelo sigue haciendo el razonamiento.

El bucle proporciona la estructura operativa.

El cambio es importante porque las sesiones de Claude son temporales.

Sin un bucle, cada ejecución comienza desde cero. Con un bucle, Claude lee lo que sucedió antes y continúa desde ahí.

6 partes que todo bucle de Claude necesita

Un bucle sin estructura es solo un prompt que se ejecuta dos veces.

Aquí están las 6 partes que hacen que un bucle funcione realmente:

→ 1. Desencadenante

Lo que inicia la ejecución.

Comando manual. Temporizador programado. Cambio en un archivo. Fallo de CI. Evento de Git.

→ 2. Contexto

Lo que Claude lee antes de actuar.

Definición de la tarea. Progreso anterior. Archivos del proyecto. Instrucciones.

→ 3. Acción

Lo que Claude hace.

Escribir un informe. Redactar una corrección. Clasificar fallos. Actualizar un documento.

→ 4. Verificación

Cómo compruebas el resultado.

Lista de verificación. Suite de pruebas. Secciones requeridas. Comprobación de límites de seguridad.

→ 5. Actualización de estado

Lo que se recuerda para la próxima vez.

PROGRESS.md actualizado. Bloqueos registrados. Próxima ejecución guiada.

→ 6. Decisión

Detener. Repetir. O escalar a un humano.

Ese es el bucle completo.

Y cada paso importa.

Saltar la verificación → el bucle confía ciegamente en sí mismo.

Saltar el estado → cada ejecución comienza desde cero.

Saltar la decisión → el bucle nunca sabe cuándo detenerse.

El sistema de 4 archivos que hace funcionar los bucles

No necesitas infraestructura.

Necesitas 4 archivos y una carpeta.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — El objetivo. Lo que este bucle intenta lograr.

LOOP_INSTRUCTIONS.md — El procedimiento operativo. Cómo debe ejecutarse Claude, qué se le permite hacer, cómo verificar.

PROGRESS.md — La memoria. Lo que sucedió la última vez, qué está bloqueado, en qué debería centrarse la próxima ejecución.

outputs/ — Donde Claude escribe los resultados. Predecible. Inspeccionable. Seguro.

Eso es todo.

Claude lee estos archivos al inicio de cada ejecución. Los actualiza al final. La próxima ejecución continúa desde donde se detuvo la anterior.

Esto es lo que hace que los bucles sean diferentes de los prompts repetidos.

El estado vive fuera del chat.

TASK.md — Define el objetivo claramente

Este archivo le dice a Claude para qué sirve el bucle.

Mantenlo a un nivel alto. No pongas detalles operativos aquí. Esos van en LOOP_INSTRUCTIONS.md.

Copia esta plantilla:

1# Bucle de Revisión Diaria del Proyecto
2
3## Objetivo
4Revisar esta carpeta del proyecto, resumir lo que cambió,
5identificar bloqueos y producir un breve informe de revisión diaria.
6
7## Resultado Esperado
8Cada ejecución debe producir o actualizar:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Alcance
13Claude puede inspeccionar archivos en este espacio de trabajo y escribir
14informes en la carpeta `outputs/`.
15
16Claude NO debe:
17- Modificar archivos fuente
18- Eliminar o renombrar archivos
19- Enviar mensajes o abrir tickets

Observa la última sección.

La primera versión de cualquier bucle debe tener reglas explícitas de "no hacer".

Esto no es porque Claude no sea de fiar.

Esto es porque tú eres un buen ingeniero.

PROGRESS.md — La memoria del bucle

Este es el archivo más importante del sistema.

Sin él, cada ejecución comienza desde cero. Con él, Claude sabe lo que pasó y continúa desde ahí.

La estructura que realmente funciona:

1# Progreso del Bucle
2
3## Estado Actual
4- Estado: Activo
5- Objetivo principal: Revisión diaria del proyecto
6- Enfoque actual: [lo que importa ahora mismo]
7- Última actualización: [fecha]
8
9## Última Ejecución
10- Fecha:
11- Resumen:
12- Archivos revisados:
13- Resultado producido:
14
15## Elementos Pendientes
16-
17
18## Bloqueos
19-
20
21## Necesita Revisión Humana
22-
23
24## La Próxima Ejecución Debería
25-
26
27## Decisiones Tomadas
28-
29
30## No Repetir
31-

La sección "No Repetir" es crítica.

Evita que Claude reintente cosas que ya fallaron.

La sección "Necesita Revisión Humana" es crítica.

Evita que el bucle continúe silenciosamente cuando no debería.

Dos reglas para mantener PROGRESS.md útil:

→ Si Claude lo necesita para decidir la siguiente acción → mantenlo en PROGRESS.md → Si solo quieres un registro → muévelo a outputs/history/

Los archivos de estado que crecen para siempre se vuelven inútiles.

Mantén PROGRESS.md como un panel de control, no como un archivo.

LOOP_INSTRUCTIONS.md — El procedimiento operativo

Este archivo es la capa de control alrededor de Claude.

Le dice a Claude exactamente qué leer, qué escribir, qué no tocar y cómo verificar el resultado antes de detenerse.

La plantilla que funciona:

1# Instrucciones del Bucle
2
3Estás ejecutando un bucle de revisión diaria del proyecto.
4
5## Antes de Empezar
61. Lee `TASK.md`
72. Lee `PROGRESS.md`
83. Inspecciona la carpeta del proyecto
94. Identifica qué cambió, qué está incompleto, qué necesita revisión humana
10
11## Lo Que Debes Hacer
12Escribe una breve revisión diaria en `outputs/daily-review.md` que incluya:
13- Resumen del estado actual
14- Archivos revisados
15- Cambios significativos
16- Bloqueos o preguntas sin resolver
17- Próximas acciones recomendadas
18
19Después de escribir, actualiza `PROGRESS.md` con:
20- Fecha de esta ejecución
21- Resumen de lo que sucedió
22- Archivos verificados
23- Lo que la próxima ejecución debe hacer
24- Si se necesita revisión humana
25
26## Reglas de Seguridad
27- No elimines archivos
28- No renombres ni muevas archivos
29- No modifiques archivos fuente
30- Solo escribe en `outputs/daily-review.md` y `PROGRESS.md`
31- Si no estás seguro de si una acción está permitida → detente y pregunta
32
33## Lista de Verificación
34Antes de finalizar la ejecución, confirma:
35- `outputs/daily-review.md` existe con todas las secciones requeridas
36- `PROGRESS.md` fue actualizado
37- No se modificaron archivos fuera de las rutas permitidas
38
39## Política de Fallos
40Si la verificación falla:
411. Sección faltante en el informe → corregir una vez
422. PROGRESS.md no actualizado → actualizar una vez
433. Archivo prohibido modificado → detenerse inmediatamente
444. Misma verificación falla dos veces → marcar como necesita revisión humana

Observa la política de fallos al final.

La mayoría de los bucles no tienen una política de fallos.

Entonces, cuando algo sale mal, Claude improvisa.

Ahí es donde los bucles crean problemas.

Define la ruta de fallo explícitamente. Siempre.

Ejecutando tu primer bucle manualmente

No programes todavía.

Ejecútalo manualmente primero.

Abre la carpeta en Claude Code o Claude Desktop/Cowork. Usa este prompt:

1Ejecuta el bucle de revisión diaria del proyecto para este espacio de trabajo.
2
3Sigue `LOOP_INSTRUCTIONS.md` exactamente.
4
5Antes de actuar, lee:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Luego inspecciona el espacio de trabajo, escribe la revisión diaria en
11`outputs/daily-review.md`, actualiza `PROGRESS.md`,
12ejecuta la lista de verificación e informa qué cambió.
13
14No modifiques ningún archivo excepto
15`outputs/daily-review.md` y `PROGRESS.md`.

Después de la ejecución, verifica dos cosas:

→ outputs/daily-review.md — informe estructurado con todas las secciones

→ PROGRESS.md — estado actualizado, guía para la próxima ejecución, indicadores de revisión humana

Si ambos se ven bien → el bucle está funcionando.

Ahora ejecútalo 3-5 veces más con pequeños cambios.

Agrega un archivo de notas. Agrega un bloqueo a PROGRESS.md. Cambia algo en el espacio de trabajo.

Cada ejecución debe recoger los cambios sin empezar desde cero.

Esa continuidad es el objetivo principal.

Verificación: la parte que la mayoría omite

Aquí está el modo de fallo del que nadie habla.

Claude ejecuta el bucle. Dice que ha terminado. Actualiza el estado. Se detiene.

Todo parece estar bien.

Pero al informe le faltan secciones requeridas. O PROGRESS.md no se actualizó realmente. O Claude editó silenciosamente un archivo que no debía.

Te das cuenta solo cuando algo se rompe.

Por eso existe la verificación.

El bucle no debe detenerse porque Claude dice que ha terminado.

Se detiene porque se verificó una condición concreta.

Una buena verificación se ve así:

Ejecuta una pasada de verificación para la última ejecución del bucle.

Verifica el resultado contra la Lista de Verificación

en LOOP_INSTRUCTIONS.md.

Informa:

1. Qué verificaciones pasaron
2. Qué verificaciones fallaron
3. Qué archivos se modificaron
4. Si la ejecución es segura de aceptar
5. Si se requiere revisión humana

No modifiques ningún archivo durante esta pasada de verificación.

Ejecuta el trabajador. Luego ejecuta el verificador. Por separado.

Con el tiempo puedes fusionarlos. Pero durante las primeras pruebas, mantenlos separados.

El verificador necesita un estándar de aprobado/reprobado.

"Revisa esto y dime si se ve bien" NO es un verificador.

"Verifica estas 7 condiciones y marca la ejecución como aceptada solo si las 7 pasan" SÍ es un verificador.

Programación con /loop

El bucle se ejecuta de forma fiable manualmente.

Ahora prográmalo.

En Claude Code, usa /loop:

1/loop 24h Ejecuta el bucle de revisión diaria del proyecto para este espacio de trabajo.
2
3Sigue `LOOP_INSTRUCTIONS.md` exactamente.
4Lee `TASK.md` y `PROGRESS.md` primero.
5Escribe el informe en `outputs/daily-review.md`.
6Actualiza `PROGRESS.md` antes de detenerte.
7Ejecuta la lista de verificación.
8Si no hay cambios significativos → mantén el informe breve.
9Si se necesita revisión humana → márcalo claramente en `PROGRESS.md`.
10No modifiques ningún archivo excepto `outputs/daily-review.md`
11y `PROGRESS.md`.

Las opciones de intervalo:

→ /loop 15m — Cadencia de prueba (úsalo mientras supervisas)

→ /loop 1h — Monitoreo por hora

→ /loop 24h — Revisión diaria

→ /loop 7d — Limpieza o resumen semanal

Importante: /loop no es magia.

Solo repite el prompt.

La calidad del bucle proviene de la estructura alrededor del prompt — los archivos, las instrucciones, la verificación, el estado.

/loop solo proporciona el desencadenante.

También conoce /goal:

/loop = ejecutar de nuevo porque pasó el tiempo.

/goal = seguir ejecutando hasta que se cumpla una condición.

1/goal outputs/daily-review.md existe, PROGRESS.md está actualizado,
2la lista de verificación pasa, no se modificaron archivos prohibidos.

Usa /loop para trabajos basados en tiempo (revisiones diarias, monitoreo).

Usa /goal para trabajos basados en finalización (arreglar hasta que las pruebas pasen, escribir hasta que todas las secciones estén listas).

La escalera de permisos

Aquí es donde la mayoría de los bucles fallan.

La gente construye un bucle que funciona. Luego inmediatamente le da demasiado poder.

El bucle publica directamente en Slack. Envía código sin revisión. Cierra tickets automáticamente.

Entonces algo sale mal y es un desastre.

Usa la escalera de permisos en su lugar:

1Nivel 1 — Solo lectura
2Claude lee archivos, tickets, registros, incidencias.
3
4Nivel 2 — Resultados borrador
5Claude escribe solo en outputs/.
6Informes, planes, recomendaciones.
7Nada externo.
8
9Nivel 3 — Ediciones en espacio aislado
10Claude modifica archivos dentro de un espacio aislado controlado.
11Rama o árbol de trabajo aislado.
12
13Nivel 4 — Acciones externas en borrador
14Claude prepara PR, mensaje de Slack, actualización de ticket.
15NO envía ni fusiona.
16
17Nivel 5 — Acciones aprobadas por humanos
18Claude aplica cambios solo después de la aprobación explícita.
19
20Nivel 6 — Acciones automatizadas de bajo riesgo
21Claude completa tareas de alcance limitado automáticamente.
22Con registros, límites y capacidad de reversión.

Tu primer bucle debe estar en el Nivel 1 o Nivel 2.

Eso no es debilidad. Es ingeniería.

Los bucles de Nivel 1 y 2 pueden seguir siendo enormemente valiosos.

Claude puede inspeccionar tus incidencias de GitHub, leer fallos de CI, revisar PRDs y resumir todo — sin tocar nada importante.

Primero demuestra que el bucle funciona en el Nivel 2.

Luego decide si merece el Nivel 3.

Cuando los bucles fallan (y cómo prevenirlo)

Primer bucle malo:

Cada día, mejora la estrategia del producto hasta que se sienta más sólida.

→ Sin condición de parada → Sin verificación → Sin estado → "Se siente más sólida" no es un elemento de la lista de verificación

Este bucle o no hará nada útil o cambiará cosas que no debería.

Primer bucle bueno:

Cada viernes, revisa el documento de estrategia del producto.

Identifica las secciones que cambiaron esta semana.

Enumera las suposiciones no resueltas.

Escribe una nota de revisión estructurada en outputs/strategy-review.md.

No edites el documento de estrategia directamente.

→ Horario claro → Alcance limitado → Archivo de salida predecible → Límite de permiso seguro

La diferencia no es la inteligencia. Es el diseño.

Las 5 cosas que hunden los bucles:

→ Programar antes de las pruebas manuales

→ Sin archivo de estado — cada ejecución comienza desde cero

→ Sin verificación — el bucle confía en sí mismo

→ Sin política de fallos — los malos resultados improvisan

→ Demasiadas herramientas demasiado pronto — el radio de explosión se expande

Arregla las cinco antes del primer comando /loop.

Agregando herramientas y conectores

Una vez que el bucle local es estable, puedes extenderlo.

GitHub. Slack. Linear. Jira. Registros de CI.

Pero cada nueva herramienta expande el radio de explosión.

Sigue el mismo principio: leer primero, borrador segundo, escribir solo después de ejecuciones exitosas repetidas.

Las reglas específicas de la herramienta van en LOOP_INSTRUCTIONS.md:

1## Política de Permisos de Herramientas
2
3### GitHub
4Permitido:
5- Leer incidencias abiertas
6- Leer estado de solicitudes de extracción
7- Leer estado de CI
8- Redactar resumen en `outputs/github-review.md`
9NO permitido:
10- Enviar commits
11- Fusionar solicitudes de extracción
12- Cerrar incidencias
13- Comentar públicamente sin aprobación
14
15### Slack
16Permitido:
17- Redactar mensaje en `outputs/slack-update.md`
18NO permitido:
19- Enviar mensajes
20- Mencionar usuarios
21- Publicar en canales
22
23### Linear/Jira
24Permitido:
25- Leer tickets asignados
26- Redactar actualizaciones sugeridas
27NO permitido:
28- Cambiar estado
29- Cerrar tickets
30- Crear tickets sin aprobación

Si la herramienta no está listada → detente y pide revisión humana.

Esto te protege de que el bucle haga cosas en las que no pensaste.

Cómo se ve tu primer bucle completo

Aquí está la configuración completa desde cero.

1## Política de Permisos de Herramientas
2
3### GitHub
4Permitido:
5- Leer incidencias abiertas
6- Leer estado de solicitudes de extracción
7- Leer estado de CI
8- Redactar resumen en `outputs/github-review.md`
9NO permitido:
10- Enviar commits
11- Fusionar solicitudes de extracción
12- Cerrar incidencias
13- Comentar públicamente sin aprobación
14
15### Slack
16Permitido:
17- Redactar mensaje en `outputs/slack-update.md`
18NO permitido:
19- Enviar mensajes
20- Mencionar usuarios
21- Publicar en canales
22
23### Linear/Jira
24Permitido:
25- Leer tickets asignados
26- Redactar actualizaciones sugeridas
27NO permitido:
28- Cambiar estado
29- Cerrar tickets
30- Crear tickets sin aprobación

Luego completa cada archivo (usa las plantillas de arriba).

Luego ejecuta manualmente:

1Ejecuta el bucle de revisión diaria del proyecto para este espacio de trabajo.
2
3Sigue `LOOP_INSTRUCTIONS.md` exactamente.
4Antes de actuar, lee TASK.md, PROGRESS.md,
5y LOOP_INSTRUCTIONS.md.
6Escribe la revisión diaria en `outputs/daily-review.md`.
7Actualiza `PROGRESS.md` antes de detenerte.
8Ejecuta la lista de verificación.
9No modifiques ningún archivo excepto
10`outputs/daily-review.md` y `PROGRESS.md`.

Luego verifica:

1Ejecuta una pasada de verificación.
2Verifica contra la Lista de Verificación en
3`LOOP_INSTRUCTIONS.md`.
4Informa qué verificaciones pasaron, cuáles fallaron,
5qué archivos se modificaron, si se requiere revisión humana.
6No modifiques ningún archivo.

Ejecuta 3-5 veces manualmente con pequeños cambios en el espacio de trabajo.

Luego programa:

1/loop 24h Ejecuta el bucle de revisión diaria del proyecto...
2[mismo prompt que el manual, prefijado con /loop 24h]

Revisa la primera semana de resultados programados antes de confiar en él.

Ese es el sistema completo.

El cambio que lo transforma todo

Antes de los bucles:

→ Escribías un prompt

→ Claude respondía

→ Mañana escribías el mismo prompt otra vez

→ Claude no tenía memoria de ayer

→ Hacías un seguimiento manual de lo que cambiaba

→ Todo se reiniciaba con cada sesión

Después de los bucles:

→ TASK.md define el objetivo una vez

→ PROGRESS.md lleva la memoria entre ejecuciones

→ LOOP_INSTRUCTIONS.md controla el comportamiento

→ Claude lee, actúa, verifica, actualiza, se detiene

→ Mañana continúa desde donde lo dejó

→ Tú revisas los resultados, no los prompts

El cuello de botella pasa de generar trabajo a revisar trabajo.

Esa es la verdadera ventaja.

No estás haciéndole mejores preguntas a Claude.

Estás diseñando un sistema que sigue funcionando sin ti.

10 bucles que puedes construir esta semana

→ Revisión diaria del proyecto — lee el espacio de trabajo, escribe un resumen

→ Extractor de seguimiento de reuniones — convierte notas en elementos de acción

→ Planificador de limpieza de carpetas — organiza, propone, no toca

→ Clasificación de fallos de CI — lee registros, clasifica fallos, redacta investigación

→ Resumidor de incidencias de GitHub — lee incidencias abiertas, agrupa por tema

→ Asistente de revisión de PR — lee el diff, señala problemas potenciales

→ Bucle de investigación para boletín — recopila fuentes, redacta resúmenes

→ Buscador de lagunas en documentación — lee documentos, señala secciones faltantes

→ Redactor de reunión diaria — lee PROGRESS.md, escribe la reunión diaria

→ Bucle de retrospectiva semanal — revisa la semana, identifica patrones

Cada uno de estos comienza con el mismo sistema de 4 archivos.

Lo único que cambia es TASK.md y LOOP_INSTRUCTIONS.md.

Si esto te fue útil:

→ Compártelo para que llegue a todos los desarrolladores que usan Claude

→ Sigue a @sairahul1 para más sistemas que funcionan sin ti

→ Marca esto como favorito — las plantillas están listas para copiar y pegar

Suscríbete a theaibuilders.co para más artículos interesantes como este

Escribo sobre IA, creación de productos y sistemas de automatización.