Casi todo el mundo sigue usando la IA en modo pregunta-respuesta. Escribes un prompt, lees lo que salió, corriges, vuelves a escribir. El trabajo avanza mientras tú estés sentado ahí, y se detiene en el segundo que te paras por un café.
Dentro del equipo que construye Claude Code la forma de decirlo ya cambió: el trabajo no es escribir prompts, es escribir loops. Un loop es un prompt que se vuelve a disparar solo, que revisa su propio resultado y que sabe cuándo parar. Es la diferencia entre tener una herramienta y tener un proceso.
Esta guía es el desarme de un loop en sus cinco piezas, dónde vive cada una y cómo se escribe la primera. Al final está la carta de loop: una plantilla corta que llenas y que te deja uno corriendo hoy.
Qué es un loop, en una frase
Un loop es una tarea con disparador, contexto, acción, verificación y condición de salida, de modo que se ejecute sin que tú inicies cada vuelta.
Fíjate en lo que no dice: no dice que sea autónomo, ni que no lo supervises. Un loop bien hecho te quita el trabajo de arrancarlo, no el de decidir qué hace. La parte de juicio sigue siendo tuya. Lo que se automatiza es la repetición.
Las cinco piezas
1. El disparador
Qué hace que empiece la siguiente vuelta. Hay tres formas y se eligen por lo que quieres que marque el ritmo:
- El reloj.
/loopdentro de una sesión abierta corre un prompt cada tanto:/loop 15m revisa si el deploy terminó. Las unidades sons,m,hyd. Si omites el intervalo, Claude elige uno entre iteraciones según lo que vio. - El turno anterior.
/goaldispara una vuelta nueva cada vez que Claude termina de responder, hasta que se cumpla la condición que escribiste. - Un evento. Una rutina en la nube con
/schedulepuede arrancar por horario, por una llamada HTTP a su endpoint, o por un evento de GitHub como un pull request abierto.
Dónde vive: en la sesión (/loop, /goal) o en tu cuenta (rutinas de /schedule, que corren aunque tu máquina esté apagada).
2. El contexto
Lo que el loop sabe sin que se lo digas cada vuelta. Es la pieza que más se subestima y la que decide si la vuelta número veinte sale igual de bien que la primera.
Va en archivos, no en el prompt: tu CLAUDE.md con las reglas del proyecto, los datos que el loop necesita leer, y los conectores a las herramientas donde vive la información real. Si el loop tiene que preguntarte algo para poder trabajar, no es un loop: es una conversación con retraso.
Dónde vive: CLAUDE.md, archivos del repositorio, conectores y, para el prompt por omisión de /loop, un archivo .claude/loop.md en el proyecto o ~/.claude/loop.md para todos.
3. La acción
El trabajo de la vuelta. Aquí la regla es una sola: que quepa en una vuelta. Un loop que intenta hacer cinco cosas se atora en la tercera y se queda ahí para siempre.
Si la acción tiene más de tres pasos, sácala del prompt y métela en una skill. El prompt del loop se vuelve entonces una línea —/loop 30m /reporte-de-pauta— y los pasos viven en un archivo que puedes corregir sin tocar el loop.
Dónde vive: el prompt del loop para acciones simples; una skill en .claude/skills/ para todo lo demás.
4. El verificador
Cómo se sabe que la vuelta salió bien. Sin esta pieza no tienes un loop, tienes un generador de trabajo que nadie revisa.
Lo mejor es algo determinista: un comando que devuelve cero o distinto de cero, un conteo de filas, un archivo que existe o no existe. Cuando no hay forma determinista, /goal pone un modelo chico a leer la conversación y emitir un veredicto después de cada turno. Ese evaluador no corre comandos ni abre archivos por su cuenta, así que la condición tiene que ser algo que el propio trabajo de Claude deje escrito en la conversación.
Dónde vive: un script tuyo, un hook de tipo Stop, o la condición de /goal.
5. La condición de salida
Cuándo para. La respuesta "cuando yo lo apague" no cuenta, porque se te va a olvidar.
Un loop de /goal termina cuando el evaluador dice que la condición se cumplió, o cuando juzga que es imposible cumplirla. Un loop por intervalo lo detienes con Esc mientras espera la siguiente vuelta, y de todas formas las tareas recurrentes de sesión caducan a los siete días. Escribe también un tope adentro de la condición: algo como "o detente después de 20 turnos" evita que un loop mal planteado siga gastando.
Dónde vive: la condición de /goal, el tope de turnos que tú escribas, o la caducidad automática.
El paso que todo mundo se salta: el verificador. La gente escribe disparador, contexto y acción, prende el loop y se va. A la tercera vuelta el loop está repitiendo un error con mucha disciplina. Antes de prender nada, contesta esto en una línea: ¿qué comando o qué salida me dice, sin que yo lea todo, que esta vuelta sirvió? Si no puedes contestarlo, todavía no tienes un loop.
La carta de loop
Esta es la plantilla. Llénala antes de escribir una sola línea de prompt. Si una casilla queda vacía, el loop no está listo.
CARTA DE LOOP
Nombre del loop:
Qué problema resuelve (una frase, sin adornos):
1. DISPARADOR
Arranca por: [reloj cada ___ / fin del turno anterior / evento: ___]
Frecuencia máxima razonable:
Qué pasa si se salta una vuelta:
2. CONTEXTO
Archivos que lee cada vuelta:
Herramientas o conectores que necesita:
Reglas fijas que no debe volver a preguntarme:
Datos que NO debe tocar:
3. ACCIÓN
Lo que hace en una vuelta (máximo 3 pasos):
1)
2)
3)
Dónde deja el resultado:
4. VERIFICADOR
Señal de que la vuelta salió bien:
Comando o salida que lo demuestra:
Qué hace si falla: [reintenta / se detiene y avisa / escala a mí]
5. CONDICIÓN DE SALIDA
Termina cuando:
Tope duro (turnos, tiempo o costo):
Cómo lo apago a mano:
RIESGO
Lo peor que puede pasar si se equivoca 20 veces seguidas:
Qué acción irreversible tiene prohibida:La última sección es la que más gente borra y la que más importa. Un loop equivocado no comete un error: comete el mismo error muchas veces, rápido y sin que nadie lo vea.
Un loop real, llenado
El ejemplo que uso con equipos de marketing: el reporte de pauta. Cada lunes alguien entra a la cuenta de anuncios, baja números, los pega en una hoja y escribe tres bullets. Cuarenta minutos, cero criterio, y siempre se atrasa.
Llenado queda así. Disparador: rutina en la nube, lunes por la mañana. Contexto: la cuenta de anuncios por conector, más un archivo con las metas del trimestre y la definición de qué cuenta como resultado. Acción, en tres pasos: bajar los números de la semana, compararlos contra las cuatro anteriores, y escribir solo las desviaciones. Verificador: el reporte tiene que traer la fecha de corte y el gasto total, y el gasto total tiene que cuadrar con la plataforma; si no cuadra, el loop se detiene y avisa en vez de publicar. Condición de salida: es un loop permanente, con revisión mía cada mes para ver si sigue sirviendo. Riesgo: no tiene permiso de pausar, activar ni cambiar presupuestos de nada. Solo lee.
Ese último detalle es el que convierte un experimento en algo que puedes dejar corriendo. El loop lee y escribe un documento. Las decisiones de gasto siguen pasando por una persona.
El error de arranque
Casi todos empiezan por el loop más ambicioso que se les ocurre: el agente que atiende clientes, el que publica solo, el que administra la operación entera. Ese loop no se termina nunca porque no hay forma de verificar una vuelta.
Empieza al revés: busca la tarea más aburrida y más verificable que haces cada semana. Aburrida para que no te duela equivocarte, verificable para que la pieza cuatro sea trivial. Escribe su carta de loop, ponlo a correr siete días, y léelo todos los días aunque no falle.
Cuando ese primero lleve un mes sin que lo toques, ya sabes cómo se siente un loop sano y puedes subir de tamaño. Antes de eso, cada loop nuevo que prendas es una fuente de trabajo, no un ahorro. Si quieres ver los comandos que ejecutan todo esto, sigue con deja de ser niñera de Claude, y para blindarlo antes de soltarlo, con las listas de permitidos y prohibidos.