Loops en Claude Code: de niñero a gerente

Piensa en cómo trabajas hoy con Claude: le das una instrucción, lees lo que te regresa, le dices qué corregir y le vuelves a escribir. Si tú no tecleas, nada pasa. Eres su niñero. Un loop es un sistema que hace ese trabajo de ida y vuelta sin ti, en cuatro pasos que se repiten:

1. 1

   Planea

   Mira la meta y lo que ya está hecho, y elige la siguiente tarea.

2. 2

   Hace

   Trabaja esa tarea: escribe, corrige, busca, corre lo que tenga que correr.

3. 3

   Se revisa

   Compara lo que hizo contra el criterio que le diste. Si no pasa, lo arregla.

4. 4

   Decide

   Sigue con la próxima, se detiene porque ya terminó, o te busca porque te necesita.

Y vuelve al paso 1, hasta que la meta se cumple o te necesita.

Los dos dicen lo mismo: tu trabajo pasa de escribir prompts a escribir el sistema que los escribe. Eso sí, tiene su chiste. Entre más hace la IA sola, menos sabe de lo que está construyendo si no le dejas por escrito la meta y el avance. Las secciones 05 y 06 son justo eso.

No hay configuración, ni panel, ni archivo que editar. Un loop se arma con una sola línea dentro de Claude Code, y esa línea tiene tres piezas:

Claude confirma la tarea y a partir de ahí corre cada 10 minutos mientras la sesión siga abierta. Tu primer loop ya quedó. Y si ya tienes una skill que corres a mano a cada rato, también puede ser la tarea:

El modo intervalo es el más directo: tú fijas el ritmo y Claude lo respeta. Las unidades son cuatro:

Letra fina: el reloj de Claude cuenta en minutos, así que un /loop 30s corre cada minuto, no cada 30 segundos. Y los intervalos que no caben parejo en el reloj, como 7m o 90m, se redondean al más cercano que sí cabe. Claude te dice cuál eligió antes de arrancar.

Seis loops de intervalo listos para copiar. Cambia los detalles por los tuyos:

Ahora quita el intervalo y el loop cambia de naturaleza: le dejas a Claude la decisión de cuándo volver a revisar. Es el modo para cuando no sabes cuánto va a tardar algo.

¿Fijo o dinámico? Regla simple: si tu pregunta es «cada cuánto», usa intervalo (el correo cada 30 minutos). Si tu pregunta es «hasta que pase algo», usa dinámico (esperar a que termine el build). El dinámico además se frena solo, así que es el indicado para tareas con final.

Esta es la parte que casi todos hacen mal, y la que separa un loop que sirve de uno que da vueltas para siempre o se apaga antes de tiempo: a un loop dale una meta, no una tarea.

Aterrízalo. Le pides un resumen de una página sobre cualquier tema: esa es la tarea. Lo que lo vuelve un loop de verdad es la meta que le pones encima:

Sin esa meta, ahí es justo donde la IA te avienta links que ni existen y tú te enteras demasiado tarde. Con la meta puesta, Claude entra link por link a confirmar que abre y dice lo que prometía, porque ese es el criterio que le diste para dar el trabajo por terminado.

Si lo que quieres es exactamente eso, una meta verificable y que no pare hasta cumplirla dentro de la misma conversación, Claude Code tiene un comando hecho para ello: /goal. Le das la condición y, al final de cada vuelta, un modelo rápido revisa si ya se cumplió; si no, arranca otra. Es el mismo principio, vuelto comando. Tiene su propia guía: /goal.

Quiero armar un /loop pero mi meta es vaga y no sé si Claude va a saber cuándo terminó. Mi meta es: «[escribe aquí tu meta, por ejemplo: revisar que mi landing quede bien]». Reescríbela como una meta medible: que lleve un número o una lista concreta que Claude pueda contar y verificar solo en cada vuelta. Dame 2 versiones (una más estricta y una más relajada), explícame en una línea cómo sabrá Claude que ya la cumplió, agrégale un tope de vueltas razonable por si se atora, y dime si me conviene más un /loop dinámico o el comando /goal para esta meta.

Un loop con meta ya trabaja solo. El gerente va un paso más allá: tiene una lista de tareas, reparte el trabajo vuelta por vuelta, revisa cada entrega y solo te busca cuando de verdad te necesita. Se arma con tres piezas, y dos de ellas son archivos de texto.

La bitácora es la respuesta a lo que más falla cuando la IA trabaja sola: entre más vueltas da, menos se acuerda de por qué empezó. La conversación crece, se resume y se pierden detalles. Un archivo no se pierde. Si cada vuelta arranca leyendo dónde va y termina escribiendo qué hizo, la vuelta 30 sabe lo mismo que la primera. Y tú, al volver, lees un archivo en vez de todo el historial.

Las tres veces que te busca

Antes de soltarlo: un loop no cambia tus permisos. Si Claude te tiene que pedir permiso para cada archivo que toca, el loop se va a quedar parado esperándote a la primera vuelta. Antes de soltarlo, decide qué puede hacer sin preguntar en esa carpeta.

1. 1Corre el prompt de abajo en la carpeta del proyecto. Te hace tres preguntas y escribe los dos archivos.
2. 2Lee progreso.md y revision.md. Corrige lo que no te cuadre: son tuyos, no de Claude.
3. 3Pega la línea de /loop que te dio. Si la quieres con tope, usa la segunda versión.
4. 4Cuando vuelvas, abre la sección «Te necesito» de progreso.md. Es lo único que tienes que leer.

Quiero dejar de ser el niñero de Claude y armar un loop que funcione como gerente: que planee, haga una tarea, se revise solo y decida qué sigue. Antes de escribir nada, hazme 3 preguntas: qué quiero lograr al final, qué cosas puede hacer sin preguntarme y en qué casos sí tiene que buscarme. Con mis respuestas crea dos archivos en esta carpeta. Uno, progreso.md: la meta en una línea, la lista de tareas pendientes en orden (cada una lo bastante chica para terminarse en una vuelta), una sección «Hecho» y una sección «Te necesito» para lo que solo yo puedo resolver. Dos, revision.md: de 3 a 6 comprobaciones concretas que una tarea tiene que pasar para darse por buena, cada una algo que se pueda verificar mirando un archivo o corriendo algo, nada de «que quede bien». Al final dame la línea de /loop lista para copiar: que en cada vuelta lea progreso.md, tome la siguiente tarea, la revise contra revision.md, anote qué hizo y qué sigue, y que pare cuando la lista llegue a cero o después de 15 vueltas.

Tengo un /loop que hace esto: «[describe en una línea qué hace tu loop]». Lo que me entrega sale flojo y creo que es porque no tiene contra qué revisarse. Escribe un archivo revision.md con entre 3 y 6 comprobaciones que cada entrega tiene que pasar. Reglas: cada comprobación se tiene que poder verificar sin mi opinión (un número, una lista, un archivo que existe, un link que abre, un comando que sale sin errores); nada de «que quede bien» ni «que sea claro». Ordénalas de la más importante a la menos. Después reescríbeme la línea de mi /loop para que al final de cada vuelta revise su trabajo contra revision.md y, si algo no pasa, lo arregle antes de seguir.

¿Quieres que la revisión la haga alguien que no sea el mismo que hizo el trabajo, o cerrar el loop con un Stop hook? Eso ya es escribir un estándar de verdad, y tiene su propia guía: Loop de verificación.

Un loop no es gratis. Cada vuelta gasta de tu plan como si le hubieras escrito tú, y como corre solo, puede gastar mientras duermes. La diferencia entre un loop que cuesta poco y uno que te deja sin plan a media semana está en cómo lo armas.

Seis reglas para que un loop gaste poco

Este es mi loop: «[pega aquí tu línea de /loop]». [Opcional: esto dice /usage de ese loop: vueltas, tokens totales y tokens por vuelta.] Quiero que gaste menos de mi plan sin perder lo que hace. Revísalo con estas preguntas y dime qué cambiarías en cada una: 1) ¿El intervalo va con qué tan rápido cambia lo que vigila, o está revisando algo que casi nunca cambia? 2) ¿Le conviene más el modo dinámico, o escuchar el proceso en vez de preguntar cada rato? 3) ¿Tiene un final claro o un tope de vueltas? 4) ¿Hay trabajo en cada vuelta que podría hacerse una sola vez al principio? 5) ¿Me avisa solo cuando hay algo, o me escribe en cada vuelta? Al final dame la línea nueva lista para copiar y explícame en dos líneas por qué va a gastar menos.

Los comandos para mantener chica la conversación (/compact, /clear, /context) tienen su propia guía: Ahorra tokens en Claude Code.

Hay un tercer modo escondido: /loop a secas, sin tarea. Claude corre una rutina de mantenimiento incorporada: sigue con el trabajo que quedó a medias, cuida el pull request de la rama en la que estás (comentarios de revisión, pruebas que fallan, conflictos) y, si no hay nada pendiente, hace pasadas de limpieza como buscar bugs o simplificar código. Lo que no tiene vuelta atrás, como hacer push o borrar, solo lo hace si ya se lo habías autorizado en la conversación.

¿Y quién escribe ese loop.md? Claude. Este prompt lo arma por ti:

Explora este proyecto y escribe un archivo .claude/loop.md con mi rutina de mantenimiento para el comando /loop. Incluye solo revisiones que tengan sentido aquí: correr los tests si existen, revisar errores de lint o tipos, buscar TODOs nuevos, y avisarme solo si algo necesita mi atención. Deja claro que nada irreversible (borrar, publicar, hacer push) se hace sin preguntarme. Hazlo corto y en español, y explícame en 2 líneas cómo lo usa /loop cuando lo corro sin argumentos.

Un loop sin freno da miedo, así que esto va antes de que armes el primero en serio. Cuatro formas de detenerlo, de la más rápida a la más drástica:

Antes de montar tu ejército de loops, los límites reales, tal como vienen en la documentación:

Nada de esto es un defecto escondido: es el diseño. /loop está hecho para acompañar sesiones de trabajo vivas. Para lo permanente y desatendido existe el siguiente capítulo.

/loop tiene un hermano que corre en la nube de Anthropic: las rutinas, que se crean con /schedule (también responde como /routines). Hacen lo mismo; lo que cambia es dónde viven:

Regla de bolsillo: si la tarea acompaña tu sesión de trabajo, /loop. Si tiene que correr aunque tu computadora esté apagada, /schedule. El hermano de la nube tiene su propia guía completa en la bóveda: Schedule: agentes en la nube.

En la guía ya van 15 loops; estos 3 completan los 18. Pero primero ubícate, porque los loops no son solo para quien programa:

¿Ninguno te queda exacto? Estos tres prompts te arman los tuyos. El primero te entrevista, el segundo encuentra lo que ya le pides a Claude todos los días y el tercero se pega al final de cualquier loop con final:

Quiero empezar a usar /loop pero no sé qué loops me convienen. Hazme 5 preguntas cortas sobre mi trabajo (a qué me dedico, qué reviso manualmente cada día, qué se me olvida revisar, qué herramientas tengo conectadas, qué proyecto tengo abierto). Con mis respuestas, proponme 5 loops concretos: para cada uno dame la línea exacta de /loop lista para copiar, dime si le conviene intervalo fijo o modo dinámico (sin tiempo) y por qué, ponle una meta que se pueda contar, y márcame si alguno sería mejor como /schedule porque necesita correr con mi computadora apagada.

Revisa esta conversación y busca las cosas que te pido una y otra vez: revisar algo, arreglar algo, resumir algo, avisarme de algo. Hazme una lista de las 3 que más repito. Para cada una dime: cuántas veces más o menos te la pedí, cuál sería la línea de /loop que la haría sola (con intervalo fijo si pasa cada cierto tiempo, o sin intervalo si es «hasta que pase algo»), cuál es su meta medible y cuándo me tendría que buscar. Si alguna no vale la pena como loop porque pasa muy poco, dilo.

…y cuando termines (porque se cumplió la meta, llegaste al tope de vueltas o te atoraste), escribe un archivo reporte-loop.md con: qué se logró, en una lista; qué quedó pendiente y por qué; cualquier cosa que tuviste que asumir sin preguntarme; lo que necesito revisar o aprobar yo, en orden de importancia; y cuántas vueltas diste. Corto, en español, y sin repetir lo que ya está en progreso.md.