Cómo montar tu primer loop

Cuando le pides algo a la inteligencia artificial, ella produce algo y se detiene. El que revisa si quedó bien eres tú. Y si no quedó bien, el que vuelve a pedirlo también eres tú.

Un loop cambia quién hace esa parte. Anthropic lo define de forma bien simple: agentes que repiten ciclos de trabajo hasta que se cumple una condición de parada. Toda la diferencia está en el final de esa frase. Con el prompting normal, la IA para cuando produce algo. Con un loop, para cuando alcanza la meta que tú le pusiste. Entre esos dos momentos hay un abismo, y ese abismo es todo el trabajo de revisión que hoy estás haciendo tú.

La frase que originó todo esto es de Boris Cherny, el creador de Claude Code, en el escenario de Acquired Unplugged, el evento en vivo del podcast Acquired. El clip le dio la vuelta al mundo en junio de 2026:

Yo ya no le escribo prompts a Claude. Tengo loops corriendo que le escriben los prompts a Claude y averiguan qué hacer. Mi trabajo es escribir loops.

Esta guía va en tres partes. Primero qué es un loop y de qué piezas está hecho. Después cómo se construye, paso por paso. Y al final construimos uno entero, de principio a fin, sobre un caso real.

Todo esto vive dentro de Claude Code, que es Claude trabajando directo en tu computador y con tus archivos, no en una ventanita de chat. Existe como aplicación de escritorio y como herramienta de terminal, y a lo largo de la guía te doy las dos rutas.

Qué es un loop, y de qué está hecho

Un prompt es una instrucción: haz esto. Un loop es una instrucción más una condición de salida: haz esto, y no pares hasta que se cumpla aquello.

Esa condición es lo que hace que Claude, al terminar un intento, no te lo entregue sino que lo compare contra lo que le pediste, vea que todavía no llega, se escriba él mismo el siguiente prompt y vuelva a intentar. Tú entras al final, cuando ya cumple.

Para que eso funcione hacen falta seis piezas. Cuatro son el loop en sí y dos son extras que se agregan cuando los necesitas:

La vara de calidad, que se llama Skill

Una Skill es un archivo con instrucciones guardadas sobre cómo se hacen las cosas en tu negocio. La escribes una vez y dejas de explicar tu proyecto desde cero cada vez que abres.

En un loop cumple una función más importante que ahorrarte explicaciones: es donde vive el estándar contra el que se mide el trabajo. La recomendación oficial de Anthropic para que un loop se revise a sí mismo de verdad es exactamente esa, escribir tus pasos de verificación como una skill.

El revisor, que es un subagente

Un subagente es un ayudante con un solo encargo. Corre en su propia ventana de contexto, con su propio prompt de sistema y con las herramientas que tú le permitas, hace lo suyo y te devuelve nada más el resultado.

En un loop sirve para una cosa concreta y no negociable: el que hace el trabajo no puede ser el mismo que lo revisa. Un agente que se autoevalúa tiende a aprobarse. Uno distinto, que llega sin haber escrito nada y con la única instrucción de encontrar lo que está mal, encuentra lo que está mal.

La meta, que se pone con /goal

Es la condición de parada. Sin ella no hay loop, y por eso tiene su propia sección más abajo: es la pieza donde se decide si esto funciona o no.

El disparador, que se llama Routine

Es lo que hace que el loop arranque solo a una hora, en vez de arrancar cuando tú te acuerdas de pedirlo. Existe en tres versiones según dónde quieras que corra: en tu computador, en la nube, o solo mientras tengas la sesión abierta.

Los cables, que se llaman Connectors

Son lo que conecta a Claude con tu correo, tu calendario, tu base de datos, tu Notion o tu Slack. Sin ellos Claude te habla de esas herramientas. Con ellos entra y las mueve.

La señal de que te falta uno es concreta: si te descubres copiando y pegando datos de otra herramienta hacia el chat, ese es el connector que te hace falta.

El espacio aislado, que se llama worktree

Es una copia separada de tu proyecto, con sus propios archivos, que comparte la misma historia y el mismo repositorio que tu carpeta principal. Traducido a lo que te importa: dos agentes trabajando al mismo tiempo sin pisarse. Uno construye una función nueva mientras el otro arregla un error, y ninguno toca los archivos del otro.

Antes de empezar: la regla que decide si tienes un loop o un prompt largo

Esta es la parte que casi todo el mundo se salta y la que hace que lo demás funcione o no funcione.

Una tarea le dice a Claude qué hacer. Una meta le dice cuándo puede parar. Y tu meta tiene que tener números, porcentajes o una lista de chequeo amarrada.

El motivo es concreto. Después de cada turno, un modelo aparte lee la conversación y responde sí o no a la pregunta de si ya se cumplió la condición. Ese modelo no ejecuta comandos ni abre archivos por su cuenta: solamente lee lo que Claude ya mostró. Así que tu condición tiene que ser algo que el propio trabajo de Claude pueda demostrar sobre la mesa.

Una meta que dice "que quede bien hecho" es inútil, porque no hay forma de que nada demuestre eso. Una meta que dice "los diez resultados están verificados uno por uno y cada link abre" sí funciona, porque Claude tiene que ir, abrirlos, y el resultado queda escrito en la conversación.

Una meta bien escrita casi siempre tiene tres cosas:

• Un estado final medible. Un resultado de test, una cuenta de archivos, una lista vacía.
• Una forma de comprobarlo. Que npm test salga en cero, que git status esté limpio.
• Un techo. Un "o para después de X intentos", para que sepas cuál es el peor caso.

Si tu meta no tiene la primera, todavía no tienes un loop. Deja de leer y reescríbela hasta que la tenga, porque los cuatro pasos que vienen se apoyan en ella.

¿Cómo se construye un loop?

Son cuatro pasos, y van en este orden porque cada uno necesita el anterior. Primero defines qué es un buen resultado, después creas a quien lo juzga, después le pones la condición de parada, y al final le pones la hora a la que arranca solo.

Paso uno: escribe la vara de calidad

Antes que nada hay que dejar escrito qué es un buen resultado. Si eso no existe en ningún lado, cada vuelta del loop se va a medir contra un criterio distinto y nunca vas a llegar.

Eso se escribe en una Skill, y la forma más fácil de crearla es no crearla tú: se la dictas a Claude. Le escribes normal, "créame una skill que se llame resumen-semanal con estos puntos", le pegas tu lista, y él crea la carpeta y el archivo donde van y te confirma dónde quedaron. Funciona igual en la app de escritorio que en la terminal, y es la ruta que te recomiendo si nunca has creado un archivo de configuración.

Si prefieres crearla a mano, va en tu carpeta personal para que te sirva en todos tus proyectos:

mkdir -p ~/.claude/skills/nombre-de-la-skill

o en .claude/skills/nombre-de-la-skill/ dentro de un proyecto, si es solo para ese. Un aviso si vas a buscarla por el Finder: las carpetas que empiezan con punto vienen ocultas en Mac, y se muestran con Cmd + Shift + punto.

Adentro va un archivo llamado exactamente SKILL.md. Empieza con un encabezado entre dos líneas de tres rayitas, como el que vas a ver en el ejemplo más abajo: ahí el nombre se convierte en el comando que vas a escribir, y la descripción es lo que Claude lee para decidir si la usa sola. No hace falta reiniciar nada, Claude detecta el archivo en segundos. La única excepción es cuando la carpeta skills no existía antes de abrir la sesión, y ahí sí toca reiniciar una vez.

Dos campos opcionales que valen oro. Si quieres que una skill solo corra cuando tú la llames, y que Claude nunca la dispare por su cuenta, le agregas disable-model-invocation: true. Y si quieres que ciertas herramientas no le pidan permiso durante esa skill, las listas en allowed-tools:

---
name: desplegar
description: Despliega la aplicación a producción
disable-model-invocation: true
allowed-tools: Read, Bash
---

Paso dos: crea el revisor

Ahora hace falta alguien que compare el resultado contra esa vara, y que no sea quien lo escribió. Ese es el subagente revisor, y es la pieza que convierte un loop terco en uno que de verdad mejora.

La forma más rápida de crearlo es pedírselo a Claude escrito normal, diciéndole qué debe revisar, que sea de solo lectura y con qué modelo quieres que corra. Él escribe el archivo.

Si lo quieres escribir tú, va en ~/.claude/agents/ para que te sirva en todos tus proyectos, o en .claude/agents/ dentro de uno.

Cuatro cosas de esa configuración. El name es la identidad y tiene que ser único. El description es el campo más importante, porque es lo que Claude lee para decidir cuándo delegarle: escríbelo diciendo cuándo se usa, no solo qué hace. El tools limita lo que puede tocar, y dejarlo en solo lectura es lo que garantiza que no se ponga a arreglar en vez de reportar. El model te deja mandarlo a uno más barato.

Si creaste la carpeta agents cuando la sesión ya estaba abierta, reinicia Claude Code una vez. Después de eso, los cambios se detectan solos.

Paso tres: pon la meta

Aquí es donde las dos piezas anteriores se convierten en un loop. La meta se pone con el comando /goal seguido de la condición, escrita en español normal. Se escribe en la misma caja donde le hablas a Claude, igual en la app de escritorio que en la terminal.

Apenas la escribes, Claude arranca a trabajar sin que le mandes otro mensaje. Mientras esté activa vas a ver un indicador que dice ◎ /goal active. Después de cada turno el evaluador te dice en una línea por qué considera que todavía no se cumple, y esa razón guía el turno siguiente. Cuando se cumple, la meta se limpia sola.

Tres cosas prácticas. Solo puede haber una meta activa a la vez, y si pones otra reemplaza la anterior. Para cortarla antes de tiempo escribes /goal clear. Y /goal necesita Claude Code v2.1.139 o superior, y solo funciona en carpetas donde ya aceptaste el diálogo de confianza.

Paso cuatro: ponle el disparador

Ya tienes un loop que funciona. Falta que arranque solo, sin que tú abras nada. Eso son las Routines, y hay tres versiones según dónde quieras que corra.

La ruta fácil, que corre en tu computador. En la aplicación de escritorio haces clic en Routines en la barra lateral, luego en New routine, y eliges Local. Llenas cuatro campos: nombre, descripción corta, instrucciones, que se escriben igual que le escribirías a Claude, y horario. Debajo eliges la carpeta sobre la que va a trabajar.

Los horarios que ofrece son Manual, Hourly, Daily, Weekdays y Weekly. Si necesitas algo distinto, como cada quince minutos o el primero de cada mes, no busques el campo: se lo pides hablado y él la crea.

La condición de esta ruta es que la aplicación esté abierta y el computador despierto. Si tu computador durmió a la hora agendada, esa corrida se salta. Cuando despierta, Claude revisa si se perdió alguna en los últimos siete días y arranca exactamente una de recuperación, la más reciente. Esto importa más de lo que parece: una tarea programada para las nueve de la mañana puede terminar corriendo a las once de la noche. Si el horario te importa de verdad, escríbelo dentro del propio prompt, por ejemplo "si ya pasaron las cinco de la tarde, no lo hagas y solo dime qué quedó pendiente".

La ruta que corre aunque apagues el computador. Es la misma pantalla eligiendo Cloud, o entrando a claude.ai/code/routines. Desde la terminal se hace con /schedule:

/schedule revisión diaria de PRs a las 9am

Estas corren en la infraestructura de Anthropic, así que funcionan con el portátil cerrado, y pueden dispararse por una llamada de API o por eventos de GitHub, no solo por horario. Dos condiciones: están en los planes Pro, Max, Team y Enterprise, y trabajan sobre repositorios de GitHub. Si tu trabajo no vive en GitHub, la ruta local es la tuya. El intervalo mínimo es de una hora.

La ruta de andar por casa. Si solo quieres que algo se repita mientras tienes la sesión abierta:

/loop 5m revisa si el deploy terminó y cuéntame qué pasó

Si le quitas el intervalo y dejas solo la instrucción, Claude elige él mismo cada cuánto volver, y te dice al final de cada vuelta cuánto va a esperar y por qué. Se corta con Escape. Estas tareas viven dentro de la conversación: si cierras la terminal dejan de correr, y a los siete días se apagan solas.

Una nota sobre nombres, para que no te enredes buscando: durante un tiempo esto se llamó scheduled tasks y /schedule creaba tareas sueltas. Todo quedó unificado bajo el nombre Routines en abril de 2026. Las de la nube siguen en research preview, que es la etiqueta que usa Anthropic para lo que ya funciona pero todavía puede cambiar de forma, así que no te extrañe si algún detalle se mueve de lugar.

Ahora sí, a construir

Vamos a construir un ejemplo en el que todos los lunes necesitas un resumen de lo que se movió la semana pasada. No cualquier resumen, sino uno que cumpla un estándar, que ya venga revisado, y que esté ahí cuando abras el computador sin que tú tengas que pedirlo.

Los mismos cuatro pasos, ahora con los archivos de verdad.

La vara de calidad del resumen

Ocho puntos concretos. Fíjate en que todos se pueden comprobar leyendo el resultado, que es justo lo que pide la regla de más arriba:

---
name: resumen-semanal
description: Arma el resumen semanal de lo que se movió, con el estándar de la casa
---

Un resumen semanal está bien hecho cuando cumple estos ocho puntos:

1. Tiene entre cinco y ocho puntos, no más.
2. Los puntos están agrupados por tema, no por archivo ni por día.
3. Cada punto se entiende sin contexto técnico.
4. Cada punto dice qué cambió, no qué se tocó.
5. Lo que afecta a quien usa el producto va primero.
6. Termina con lo que quedó pendiente, si quedó algo.
7. No pasa de una página.
8. No incluye nada que no haya pasado esta semana.

Ese contenido se lo dictas a Claude tal cual, pidiéndole que lo guarde como la skill resumen-semanal. Si lo creas a mano, va en ~/.claude/skills/resumen-semanal/SKILL.md.

El revisor del resumen

Solo lee, no corrige, y termina dando una cuenta contra los ocho puntos. También se lo puedes dictar a Claude; si lo creas a mano, va en ~/.claude/agents/revisor.md:

---
name: revisor
description: Revisa el resumen semanal contra la skill resumen-semanal y encuentra lo que no cumple. Úsalo después de cada entrega.
tools: Read, Glob, Grep
model: sonnet
---

Eres un revisor. No escribes ni corriges nada: tu único trabajo es encontrar
lo que no cumple el estándar de la skill resumen-semanal.

Para cada uno de los ocho puntos, di si se cumple o no, y cuando no se cumpla,
señala exactamente dónde falla. Termina con una nota del tipo "cumple 6 de 8".

La meta del resumen

/goal el resumen semanal cumple los ocho puntos de la skill resumen-semanal,
verificado por el subagente revisor, o para después de 4 intentos

Fíjate en que esa meta cumple las tres condiciones de una meta bien escrita: los ocho puntos son el estado medible, el revisor es la forma de comprobarlo, y los cuatro intentos son el techo.

Lo que pasa a partir de ahí: Claude escribe el resumen, se lo pasa al revisor, el revisor le dice qué falta, Claude corrige, y vuelve a pasar. Cuando el revisor dice que cumple los ocho, la meta se cierra y el loop para.

El disparador del lunes

Para este caso la ruta local es suficiente. Creas una routine con horario Weekly, la pones en lunes a las nueve, eliges la carpeta del proyecto, y en las instrucciones escribes la meta. Con un detalle que importa: aquí va en prosa, no como comando.

Escribe el resumen semanal y no lo des por terminado hasta que el
subagente revisor confirme que cumple los ocho puntos de la skill
resumen-semanal. Máximo cuatro intentos.

¿Por qué no pegar el /goal del paso tres tal cual? Porque los comandos que empiezan con barra son para cuando tú los escribes en la conversación. Cuando el que dispara es un horario, la documentación no garantiza que se ejecuten como comando, y pueden llegarle a Claude como texto suelto. Escrita en prosa, la instrucción produce el mismo ciclo, Claude escribe, se lo pasa al revisor, corrige y repite, sin depender de ese detalle.

Y ya está. El lunes a las nueve, sin que tú abras nada, hay un resumen que ya pasó por un revisor que no fue el que lo escribió.

Lo que puedes añadir después

Las dos piezas que no hacen falta para tu primer loop, pero que vas a querer en el segundo o el tercero.

Los cables, cuando el loop necesita datos que no están en tu computador

El directorio revisado por Anthropic está en claude.ai/directory, y los que conectas a tu cuenta se administran en claude.ai/customize/connectors. Desde la terminal, la mayoría de los servicios se agregan así:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Para autenticarte escribes /mcp dentro de Claude Code. Ese mismo panel te sirve para ver cuáles están conectados y para apagar alguno sin borrarlo.

Hay tres lugares donde puede quedar guardada la configuración, y se eligen con --scope. El local, que es el de por defecto, la guarda solo para ti y solo en ese proyecto. El project la guarda en un archivo compartido, para que la tenga todo tu equipo. El user la guarda para ti en todos tus proyectos.

Una advertencia si usas Routines en la nube: los servidores que agregas con claude mcp add viven en tu computador, no en tu cuenta de claude.ai, así que no aparecen en la lista de connectors de una routine en la nube. Si necesitas uno allá, agrégalo desde claude.ai/customize/connectors.

El espacio aislado, cuando quieres dos loops a la vez

Esta pieza cobra sentido cuando tus loops trabajan sobre un proyecto de código guardado con Git. Si lo tuyo son resúmenes y documentos, sáltatela sin culpa y vuelve cuando la necesites.

En la aplicación de escritorio ya viene puesto: cada sesión nueva arranca en su propio worktree, y las routines locales traen un interruptor al crearlas para que cada corrida use el suyo. En la terminal se pide con una bandera:

claude --worktree resumen-semanal

Eso crea la copia en .claude/worktrees/resumen-semanal/, sobre una rama nueva, y abre Claude ahí adentro. Corres el mismo comando con otro nombre en otra terminal y ya tienes la segunda sesión aislada.

Tres cosas que ahorran dolores de cabeza. Agrega .claude/worktrees/ a tu .gitignore, o el contenido te va a aparecer como archivos sueltos. Un worktree es una copia limpia, así que tus archivos privados como el .env no están ahí: para que viajen, crea un archivo .worktreeinclude en la raíz y lista adentro lo que quieres que se copie. Y cuando sales de la sesión, Claude revisa antes de borrar: si quedó limpio lo elimina solo, si quedó trabajo adentro te pregunta, y si le pusiste nombre a la sesión también te pregunta aunque esté limpio, por si lo querías guardar.

Si quieres que un subagente siempre trabaje aislado, se lo pones en su configuración con isolation: worktree.

Los cuatro errores que hacen que esto no funcione

Poner una meta que no se puede medir. Es el error número uno y arruina todo lo demás. Si tu meta no tiene un número, un porcentaje o una lista de chequeo, todavía no tienes un loop.

Dejar que el mismo agente haga y califique. Se aprueba a sí mismo, siempre. El revisor tiene que ser otro, y de solo lectura, para que no caiga en la tentación de arreglar en vez de reportar.

No dejar nada escrito entre vuelta y vuelta. Si cada iteración arranca de cero, el loop repite los mismos errores para siempre. Que escriba en un archivo qué ya hizo y qué ya descartó.

No ponerle un techo. Un loop sin límite puede dar vueltas mucho más tiempo del que querías. El freno va dentro de la misma meta.

Por dónde empezar

No montes las cuatro piezas la primera vez. Empieza por la meta sola.

Escoge una tarea que ya le pidas a Claude a menudo y que hoy revises tú a mano. Escribe la meta con números, ponla con /goal, y mírala trabajar. En la primera vuelta vas a ver si tu meta era medible o no, porque si no lo era, el evaluador se queda dando vueltas sin poder decidir.

Cuando esa meta funcione, agrégale el revisor. Cuando el revisor esté encontrando cosas de verdad, escribe la skill con el estándar. Y solo al final ponle el disparador. En ese orden cada pieza se prueba sola y sabes cuál falló.

De dónde salió todo esto

Todo lo técnico de esta guía está verificado contra la documentación oficial de Claude Code al 29 de julio de 2026. Las funciones cambian rápido, así que si algo no te coincide, la fuente de verdad está en code.claude.com/docs.

La frase de Boris Cherny está recogida en The New Stack y en el boletín Pragmatic Engineer. La definición de loop y la recomendación de escribir la verificación como skill vienen de la guía oficial de Anthropic, Getting started with loops.

Y la documentación de cada pieza: /goal, Routines, tareas de escritorio, /loop, worktrees, skills, connectors y subagentes.