El estándar lo escribes tú una vez. Cerrarlo ya no es tu trabajo.

Le pides algo a Claude. Te lo entrega. Lo lees y no está como lo querías: le faltó el caso raro, movió algo que nadie pidió, o quedó bien pero no como lo haces tú. Se lo regresas con la corrección, te lo entrega otra vez, y ahora sí. Eso que acabas de hacer ya tiene nombre.

Se llama loop de verificación, y Anthropic lo define así: un ciclo que se repite en el que el agente revisa su propio trabajo — corre pruebas, revisores de estilo o comprobaciones que tú escribiste — y arregla lo que falla antes de seguir. Toda la definición se apoya en dos palabras: su propio. El ciclo existe cuando la revisión ya no la tienes que hacer tú.

Y hay algo que sorprende la primera vez que lo oyes: Claude ya hace un ciclo parecido dentro de un solo turno. Junta el contexto de lo que le pediste, actúa, revisa el resultado de lo que hizo y repite si hace falta, todo antes de contestarte. La maquinaria ya está puesta. Lo que no tiene es tu vara para medir el trabajo, ni tu permiso para seguir solo.

Por eso conviene abrir el loop en sus dos piezas desde ahora, porque el resto de la guía se cuelga de esa separación. Una dice con qué se mide el trabajo. La otra dice quién decide que ya está.

Que el cerrador seas tú tiene un costo que casi no se nota, porque lo pagas en cuotas chicas. Cada vuelta necesita tres cosas al mismo tiempo: que estés ahí, que te acuerdes de qué revisaste la vez pasada, y que revises con el mismo criterio de ayer. Las tres fallan.

Estar ahí falla porque tienes junta. Acordarte falla porque el jueves revisaste seis cosas y hoy te acuerdas de dos. Y el criterio falla en silencio, que es lo peor de los tres: el lunes rechazas algo que el jueves dejaste pasar, y ninguna de las dos decisiones quedó anotada en ningún lado.

Anthropic lo resume en una línea que vale la pena tener a la mano: cualquier cosa que sigas teniendo que hacer cumplir a mano, revisándola tú cada vez, es candidata a volverse un loop.

El orden de aquí en adelante es ese: primero escribes el estándar una sola vez, y después eliges quién lo cierra.

Al final vienen las recetas completas para cinco chambas reales, y los seis modos en que esto se rompe cuando se rompe.

Tu estándar ya existe. Es la lista de cosas que revisas cada vez que Claude te entrega algo: que no hayan quedado mensajes de prueba tirados en el código, que los textos estén en español, que el archivo no se haya pasado de largo, que no se tocó lo que pediste que no se tocara. La corres en automático y por eso nunca la escribiste.

El estándar no se inventa: se descubre. No te sientes a imaginar qué te gustaría exigir, porque esa lista sale bonita y no se parece a tu trabajo. Ve a lo que ya corregiste. Eso es lo único que sabes con certeza.

Anthropic lo dice en dos movimientos y funcionan tal cual. El primero: apunta todo lo que te descubres haciendo cada vez que Claude termina una función. Ese reflejo de abrir el archivo y arreglar siempre lo mismo es el dato que andas buscando. El segundo: escribe la versión de buenas prácticas en español llano, como se la darías a alguien que entra al equipo el lunes y no conoce nada del proyecto.

Ese par de frases es todo el método. Lo demás es dónde lo guardas y quién lo va a leer. Y si no confías en tu memoria para el primer movimiento, que Claude lo saque de tu historial.

Quiero descubrir mi estándar de calidad a partir de lo que ya vengo corrigiendo, no de lo que creo que me importa.

Revisa el historial reciente de este proyecto: los últimos 20 cambios guardados, los mensajes con que se guardaron cuando digan "fix", "arregla", "ajusta" o parecidos, y los archivos que más veces se tocaron seguido de otro cambio inmediato en el mismo archivo. Si tengo comentarios de revisión guardados en el proyecto, léelos también.

Con eso, contéstame tres cosas:

1. Las correcciones que se repiten. Dime cada una en una línea, en lenguaje llano, con cuántas veces la viste y un ejemplo concreto de archivo y línea. Ordénalas de más repetida a menos.

2. Cuáles de esas se pueden medir sin que alguien opine. Sepáralas en dos listas: las que un comando puede comprobar (una prueba, un conteo, una búsqueda de texto en el código, o el código de salida — el número que devuelve un comando al terminar, donde cero quiere decir que salió bien) y las que necesitan criterio humano. Para las medibles, dime exactamente con qué comando se comprueban en este proyecto.

3. Cuáles de las medibles ya están cubiertas por algo que corre solo hoy — las pruebas, el revisor de estilo, el chequeo de tipos, o el sistema que corre todo eso cada vez que se sube un cambio — y cuáles no las agarra nada. Esas últimas son las que valen la pena escribir.

No escribas todavía ningún archivo ni cambies nada. Solo entrégame las tres respuestas y espera.

Escribir esa habilidad a mano toma su rato y se te van a olvidar la mitad de los pasos. Este prompt te entrevista sobre tu chamba y deja el archivo puesto en el proyecto.

Quiero que me escribas una habilidad de verificación para este proyecto: un archivo que tú mismo vas a leer y ejecutar cada vez que yo te pida comprobar un cambio, para que dejes de entregarme trabajo a medio revisar.

Primero entrevístame. Hazme las preguntas de una en una y espera mi respuesta antes de seguir:

1. ¿Qué tipo de cambio vamos a verificar? (una pantalla, un punto de entrada de tu servicio, una migración, un documento, otra cosa)
2. ¿Qué revisas tú a mano hoy, en el orden en que lo revisas, antes de darlo por bueno?
3. De esa lista, ¿qué se puede comprobar con un comando en este proyecto, y cuál es el comando exacto?
4. ¿Qué es lo que más veces se te ha colado roto?
5. ¿Hay algo que NO se debe tocar mientras se hace este trabajo? (archivos, carpetas, pruebas, configuración)

Cuando termine de contestar, escribe el archivo en .claude/skills/verificar-<nombre-corto>/SKILL.md con estas reglas:

- El encabezado del archivo — el bloque de datos que va hasta arriba — lleva "name" y una "description" que diga en qué momento se usa esta habilidad, no solo qué hace. Si la habilidad solo debe correr cuando yo la invoque, agrégale la línea disable-model-invocation: true, que le prohíbe a Claude lanzarla por su cuenta, y dímelo.
- El cuerpo es una lista numerada de pasos. Cada paso dice qué comprobar, con qué comando, y cuál es el resultado que cuenta como aprobado.
- Cada paso termina con la instrucción de pegar la prueba en la conversación: la salida del comando, el conteo, el código de salida. Escríbelo tal cual: "pega la salida aquí, aunque sea larga".
- Al final, un paso de cierre que te obliga a repetir la lista completa con una palomita por punto y a decir explícitamente cuáles no pasaron. Si algo no lo pudiste comprobar, se reporta como no comprobado, nunca como aprobado.
- Nada de criterios de gusto. Si algo no se puede medir, no entra en el archivo: me lo dices aparte para que yo decida.

Cuando esté escrito, enséñame el archivo completo y explícame en tres líneas cómo lo voy a invocar.

El estándar escrito no cierra nada por sí solo. Es la vara. Quien decide que ya está es la otra mitad del loop, y ahí es donde casi todo el mundo se equivoca.

Vale la pena frenar aquí. Este es el dato que casi nadie tiene y el que rompe la mayoría de los loops de verificación.

Cuando le pones una condición de completitud a /goal, al terminar cada turno pasa algo muy concreto. Claude Code toma tu condición y la conversación hasta ese punto, y se las manda a un modelo chico y rápido: el evaluador. Ese modelo contesta una sola cosa, sí o no, y agrega una razón corta de por qué.

Lo que sigue depende de esa respuesta. Si dice que no, Claude arranca otro turno por su cuenta y toma esa razón como la instrucción de qué hacer ahora. Si dice que sí, la meta se limpia sola y el ciclo se acaba. Eso es todo el mecanismo, no hay más.

El detalle está en qué alcanza a ver ese modelo en el momento de decidir.

De ahí sale la regla que ordena esta guía completa: si no se ve, no cuenta. Claude pudo haber corrido la prueba, haberla visto pasar y haber seguido adelante. Si no pegó la salida en la conversación, para el que juzga esa prueba nunca ocurrió.

Esa es la causa número uno de metas que nunca se dan por cumplidas. No es que el trabajo esté mal, ni que el criterio sea imposible: es que la evidencia jamás llegó al único lugar donde el evaluador puede leerla. El ciclo da vueltas de más, la razón que devuelve suena sensata, y tú acabas pensando que el comando está descompuesto.

El ejemplo que trae la documentación oficial funciona justo por esto. Un criterio como todas las pruebas de la carpeta de autenticación pasan sirve porque, para cumplirlo, Claude tiene que correr las pruebas, y al correrlas el resultado aterriza en la conversación. El evaluador no comprobó nada: leyó lo que quedó escrito.

La documentación también es específica sobre qué trae una condición que aguanta muchas vueltas. Son tres ingredientes, y el que casi siempre falta es el tercero.

Con esos tres ingredientes en la mano, mira cómo cambia un criterio de todos los días. A la izquierda va lo que casi todos escribimos la primera vez; a la derecha, lo mismo dicho de forma que se pueda juzgar leyendo nada más la conversación.

Te voy a dar un criterio con el que quiero medir un trabajo. Necesito que lo reescribas para que se pueda juzgar leyendo solamente la conversación, sin abrir un solo archivo y sin correr un solo comando.

Mi criterio es:
[PEGA AQUÍ TU CRITERIO, COMO LO DIRÍAS EN VOZ ALTA]

Trabájalo así:

1. Dime qué parte de mi criterio es una opinión disfrazada de medida. Si dije "que quede bien", "que sea limpio", "que se vea bonito" o algo parecido, señálalo y pregúntame qué significa eso para mí en números o en una lista cerrada.

2. Conviértelo en un estado final medible: un resultado de prueba, un código de salida, un conteo de archivos, una lista vacía, un número de líneas. Uno solo, no tres.

3. Agrégale el chequeo declarado: con qué comando exacto de este proyecto se comprueba, y la orden explícita de dejar la salida de ese comando escrita en la conversación.

4. Agrégale las restricciones que importan: qué no se debe tocar para llegar ahí. Piensa en las formas de hacer trampa. Si el criterio es "las pruebas pasan", la trampa es borrar la prueba que falla; escribe la restricción que la cierra.

5. Ponle un tope: "o para después de N vueltas". Propón un número según lo grande que sea el trabajo y explícame por qué ese.

Entrégame el criterio final en una sola línea corrida, lista para copiar, y abajo una tabla de dos columnas con lo que decía antes y lo que dice ahora, punto por punto.

Mientras el que cierre sea el evaluador de /goal, tu criterio tiene que dejar la prueba escrita: es lo único que él va a poder leer. Hay una manera de tapar ese punto ciego de raíz, y no es escribir criterios más bonitos, es cambiar de cerrador por uno que sí corra los comandos. Eso llega en la sección 06.

Ya tienes la vara. Ahora falta decidir quién la aplica y en qué momento, y ahí es donde la mayoría se complica de más.

Un turno es cada vuelta completa de Claude: recibe algo, trabaja y se detiene. Los cuatro cerradores de abajo usan exactamente el mismo estándar — el que escribiste una vez y no vas a volver a tocar. Lo único que cambia de uno a otro es qué dispara el siguiente turno.

Uno de los cuatro necesita presentación. Un hook es una regla que dejas escrita en la configuración de Claude Code y que se dispara sola en un momento fijo, sin que tú la invoques. El de Stop, que es el que nos importa aquí, se dispara justo cuando Claude va a terminar el turno.

Esta sección es para elegir, no para configurar. La mecánica completa de /goal — cómo se escribe la condición, cómo revisas el estado, cómo lo apagas — está en la guía de /goal, y la de /loop, con sus modos y sus topes reales, está en la guía de /loop. Ahí está cada comando a fondo. Aquí lo único que importa es cuál te toca.

Cambias de cerrador cuando cambia el disparador. El estándar se queda donde está.

Vistos por separado, los dos comandos parecen dos maneras de hacer lo mismo. No lo son. Lo que cambia de uno a otro no es la vara con la que se mide el trabajo: es qué dispara el siguiente turno. La vara la escribes una sola vez y la enchufas donde haga falta.

Piénsalo como tres fases del mismo trabajo. Primero hay algo que hoy no cumple tu estándar y alguien tiene que llevarlo hasta que lo cumpla. Después ese algo ya cumple, y lo que quieres es que no se vuelva a caer cuando entre lo nuevo. Y al final, cuando el estándar ya se ganó su lugar, dejas de escribir el comando y se revisa solo.

No compiten. Se pasan la estafeta.

Antes de armar cualquiera de los tres pares necesitas la vara traducida al formato que entiende el comando: un estado final medible, los comandos que lo comprueban con la orden de dejar la salida pegada en la conversación, las restricciones contra los atajos y un tope de vueltas.

Ese trabajo no lo tienes que hacer a mano. Este prompt toma la habilidad de verificación que ya escribiste y la deja en esas cuatro piezas.

Ya tengo una habilidad de verificación en este proyecto. Quiero que la conviertas en una condición de completitud, esa que Claude Code sigue trabajando hasta cumplir.

Primero lee el archivo de la habilidad (búscalo en .claude/skills/, empieza por los que se llamen verificar-algo). Si hay más de uno, pregúntame cuál.

Después escríbeme la condición con estas cuatro piezas, en este orden:

1. El estado final medible. Uno solo. El que resume que el trabajo está hecho.
2. El chequeo declarado. Los comandos exactos que lo comprueban, con la instrucción de dejar su salida escrita en la conversación. Escribe "y la salida queda pegada en la conversación" de forma literal: el modelo que juzga no corre comandos, solo lee lo que ya está escrito.
3. Las restricciones. Qué no se debe modificar para llegar ahí. Piensa como alguien que quiere terminar rápido y cierra esos atajos.
4. El tope de vueltas. Propón un número y justifícalo.

Reglas duras:
- Todo va en una sola línea corrida, sin saltos, porque así se escribe el comando.
- Máximo cuatro mil caracteres. Si te pasas, recorta lo menos importante y avísame qué quitaste.
- Nada que dependa de mi gusto. Si algo del estándar no se puede juzgar leyendo la conversación, sácalo de la condición y déjalo como nota aparte para que yo lo revise a mano.

Entrégame la condición lista para copiar y, abajo, dime qué línea de mi habilidad quedó fuera y por qué.

Aquí van tres pares completos, cada uno con sus dos mitades. Lo que está entre corchetes es lo único que cambias por lo tuyo: la ruta, la carpeta, el número, el comando que usa tu proyecto.

/goal todos los textos que ve el usuario dentro de [tu carpeta] están en español, sin frases sueltas en otro idioma, y cada mensaje de error dice qué pasó y qué puede hacer la persona; para comprobarlo ve listando en la conversación cada texto que cambies con su archivo y su número de línea, y al final imprime la lista completa de textos visibles de esa carpeta para que se vea que ninguno quedó fuera; no cambies nombres de variables ni claves de traducción, no toques la lógica y no inventes textos para pantallas que no existen; para después de 8 vueltas y dime cuáles no supiste cómo redactar.

/goal la pantalla [/tu-ruta] termina de cargar en menos de [N] milisegundos, medida tres veces seguidas y con la memoria del navegador vacía; para comprobarlo corre la medición las tres veces y pega los tres números en la conversación junto con el peso de cada recurso que se descarga; para llegar ahí puedes quitar lo que no se usa, dejar para después lo que no se ve al abrir y comprimir imágenes, pero no borres funcionalidad, no dejes las imágenes por debajo de [tu calidad mínima] y no muevas trabajo a otra pantalla para que esta salga bien; para después de 10 vueltas y dime qué fue lo que más pesó.

/goal la lista de pendientes de [tu archivo o tu etiqueta] queda vacía; para comprobarlo imprime la lista completa en la conversación cada vez que cierres uno, con la línea de cada pendiente y su estado, y al final vuelve a imprimirla entera para que se vea vacía; resuelve cada pendiente de verdad — no borres la línea sin hacer el trabajo, no la muevas a otro archivo, no la comentes ni la reescribas como nota — y después de cada uno corre [el comando de pruebas de este proyecto] y deja su salida pegada en la conversación; para después de 12 vueltas, o antes si un mismo pendiente falla dos veces seguidas, y dime cuál te frenó.

Quiero armar el ciclo completo de verificación para una chamba, con las dos mitades: la que llega al estándar y la que lo mantiene.

La chamba es:
[DESCRIBE AQUÍ QUÉ QUIERES QUE SE HAGA, EN DOS O TRES LÍNEAS]

Necesito que me entregues cuatro cosas:

1. El estándar compartido. Los criterios con los que se mide esta chamba, en una lista numerada, todos medibles con un comando de este proyecto. Si alguno no se puede medir, dímelo y no lo metas.

2. La mitad que llega. La condición de completitud que empuja el trabajo hasta cumplir ese estándar: estado final medible, comandos que lo comprueban con la orden de dejar su salida escrita en la conversación, restricciones contra los atajos, y un tope de vueltas. En una sola línea, lista para copiar.

3. La mitad que mantiene. El prompt recurrente que revisa cada tanto que el estándar siga cumpliéndose sobre lo que haya entrado nuevo. Propón el intervalo según qué tan seguido cambia esto de verdad, y justifícalo. Si el trabajo tiene un final claro y no algo que vigilar, dime que esta mitad no aplica en vez de inventarla.

4. El orden. Dime cuál corro primero y cuál después, y qué señal me dice que ya puedo pasar de una a la otra. No me los pongas a correr al mismo tiempo: mientras la primera está activa, ocupa todos los turnos y la segunda casi no encuentra hueco para dispararse.

Al final, en tres líneas, dime qué parte de esto se me va a caer primero si no le hago caso.

La vara la escribes una vez. Lo único que cambias después es quién la dispara.

Los dos cerradores que ya viste tienen el mismo punto débil, y no es técnico: dependen de que te acuerdes. /goal lo escribes tú al empezar la chamba. /loop lo dejas puesto tú. El día que se te pasa, no hay estándar. Un hook no depende de eso.

Un hook es una regla que vive en tu archivo de configuración y se dispara sola en el momento del ciclo que tú elijas. Hay varios momentos disponibles; el que nos interesa aquí es el de Stop, que se dispara justo cuando Claude va a terminar el turno. O sea, exactamente cuando quieres que alguien revise antes de que te lo entregue.

Cuando digo archivo de configuración me refiero a un archivo de texto donde Claude Code guarda tus reglas fijas: lo lee al arrancar cada sesión y aplica lo que diga sin que se lo pidas. Hay dos, y ahí está la única decisión de alcance que vas a tomar: el tuyo aplica a todos tus proyectos, el del proyecto aplica solo dentro de esa carpeta.

Hay dos versiones de este cerrador, y la diferencia entre ellas es justo el punto ciego de la sección 03.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Antes de dejar terminar el turno, revisa lo que quedó escrito en la conversación. Repruébalo solo si la prueba de que algo falló ya está a la vista: un test en rojo, un error de tipos, o un comando de verificación que nunca se corrió. Si todo lo comprobable pasó, aprueba. Responde en JSON: {\"ok\": true} cuando el trabajo cierra, o {\"ok\": false, \"reason\": \"...\"} cuando falte algo, con una sola instrucción concreta de qué hacer en el siguiente turno."
          }
        ]
      }
    ]
  }
}

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Antes de dejar terminar el turno, comprueba tú mismo el estado real del proyecto. Corre todas las pruebas del proyecto y el chequeo de tipos, y abre los archivos que se tocaron en este turno. No te fíes de lo que se dijo en la conversación: lo que cuenta es lo que devuelven los comandos. Responde en JSON: {\"ok\": true} si todo pasa de verdad, o {\"ok\": false, \"reason\": \"...\"} cuando algo falle, nombrando el comando que tronó y la primera línea de su error.",
            "timeout": 300
          }
        ]
      }
    ]
  }
}

No tienes que escribir esos bloques a mano. Este prompt te arma las dos versiones con los comandos de tu proyecto, y antes de tocar nada revisa tu configuración actual para no pisar los hooks que ya tengas.

Quiero que mi estándar de verificación deje de depender de que yo me acuerde de escribir un comando. Quiero que se revise solo al final de cada turno, en todas mis sesiones de este proyecto.

Escríbeme la configuración de un hook de Stop, en las dos versiones, y explícame cuál me conviene:

VERSIÓN A — hook de prompt. El que solo lee la conversación y contesta sí o no. Barato y rápido, pero ciego: no abre archivos ni corre comandos. Escribe el prompt del hook de manera que solo repruebe cuando la prueba de que algo falló ya está escrita en la conversación, y que cuando repruebe devuelva una razón concreta y accionable, porque esa razón se le entrega a Claude como la instrucción del siguiente turno.

VERSIÓN B — hook de agente. El que sí abre archivos y corre comandos antes de decidir. Escríbelo para que ejecute los comandos de verificación de este proyecto y juzgue el resultado real, no lo que se dijo en el chat. Ponle un tiempo de espera acorde a lo que tarda mi comando de pruebas. Adviérteme que esta versión es experimental y que cuesta más por turno.

Para las dos:
- Dime en qué archivo va y por qué ahí: el de mi usuario si lo quiero en todos mis proyectos, el del proyecto si es solo para este.
- Deja fuera cualquier criterio de gusto. Si no se puede medir, no entra.
- Avísame del tope: si el hook bloquea ocho veces seguidas sin avanzar, Claude Code lo ignora y deja terminar el turno. Dime cómo escribir el criterio para que converja antes de llegar ahí, en vez de subir el tope.

Antes de escribir nada, léete mi configuración actual y dime si ya tengo hooks puestos, para no pisarlos. Luego enséñame los dos bloques completos y espera a que yo elija.

El reparto entre las tres capas queda así: /goal para una chamba puntual, /loop para vigilar algo que cambia, y el hook para el criterio que quieres que aplique siempre y en todos lados, sin que te acuerdes de nada.

Hasta aquí fue el método. Esta parte es el recetario: cinco chambas comunes ya armadas con las dos piezas, el estándar y el cerrador. Cópialas, cámbiales lo que va entre corchetes y córrelas.

Cada receta trae lo mismo en el mismo orden. Primero el estándar, que es la lista de lo que tiene que ser cierto al final. Después la condición completa para dársela a /goal, en una sola línea, lista para copiar. Después el /loop que la vuelve a revisar cada tanto, para que lo que ya lograste no se caiga solo. Y al final la línea que más se rompe en la práctica.

La ruta [/tu-ruta] carga sin errores nuevos en la consola y se ve completa a 390 píxeles de ancho. Comprueba cada punto y deja la salida pegada en la conversación, aunque sea larga: corre [tu comando de desarrollo] y pega las últimas veinte líneas del arranque; abre la ruta, pega la lista completa de mensajes de la consola del navegador y dime cuántos son errores; con la ventana a 390 píxeles de ancho, pega el ancho del documento y el de la ventana y confirma que el primero no es mayor; enséñame con archivo y número de línea dónde vive el estado de carga y dónde el de error. No toques archivos fuera de [tu carpeta], no borres ni escondas contenido para que deje de desbordarse, y no silencies mensajes de la consola. Para después de 6 vueltas y dime qué quedó pendiente.

Ningún archivo dentro de [tu carpeta] pasa de [N] líneas. Comprueba así y deja la salida pegada tal cual sale, sin resumirla: cuenta las líneas de todos los archivos de esa carpeta, ordena la lista de mayor a menor y pégala completa; corre [tu comando de pruebas] y pega el resumen final con el número de pruebas y el código de salida. No borres código para bajar el conteo: lo que salga de un archivo entra en otro del mismo proyecto. No modifiques ninguna prueba para que pase, no toques nada fuera de [tu carpeta] y no dejes ninguna referencia apuntando a un archivo que ya no existe. Para después de 8 vueltas y dime qué archivos quedaron arriba del tope y por qué.

La auditoría de seguridad de dependencias devuelve cero avisos pendientes. Comprueba así y deja pegada en la conversación la salida completa de cada comando, aunque sea larga: corre [tu comando de auditoría] y pega el reporte tal cual, con el conteo por severidad; corre [tu comando de construcción] y pega las últimas quince líneas junto con el código de salida; corre [tu comando de pruebas] y pega el resumen. Pega también la lista de archivos modificados: ahí solo pueden aparecer los archivos de dependencias. No cambies código propio para acomodar una versión nueva, no fijes una versión vieja para esquivar un aviso y no uses la opción que ignora avisos. Si un paquete no se puede subir sin tocar código, no lo subas: dime su nombre y qué se rompe. Para después de 5 vueltas.

La revisión automática de accesibilidad devuelve cero errores en [las pantallas de tu flujo]. Comprueba así y deja pegado en la conversación todo lo que salga: corre [tu comando de revisión de accesibilidad] sobre cada pantalla del flujo y pega el reporte de cada una, con el conteo de errores y el de advertencias; aparte, escribe el recorrido con teclado paso por paso, diciendo qué elemento recibe el foco en cada tabulación y en qué punto se puede enviar el formulario sin tocar el ratón. No desactives ni una regla de la revisión, no le pongas texto alternativo vacío a una imagen que sí comunica algo, y no cambies colores ni tamaños del diseño para subir el contraste sin avisarme primero qué vas a cambiar. Para después de 6 vueltas y enséñame qué quedó como advertencia.

El registro de cambios cubre todo lo que entró desde [tu última versión publicada], y todos los comandos y enlaces de la documentación existen. Comprueba así y deja las tres listas pegadas en la conversación: pega la lista de cambios que entraron desde esa versión y, junto a cada uno, la entrada del registro que lo cubre o la palabra falta; corre cada comando que aparezca en el archivo de instrucciones y pega una lista de dos columnas con el comando y su código de salida; pega la lista de enlaces internos con el destino de cada uno y si existe o no. No modifiques ningún archivo de código, no borres entradas viejas del registro para acomodar las nuevas y no inventes una entrada para un cambio que no entiendas: si no sabes qué hizo, escríbelo como pendiente de revisar. Para después de 4 vueltas.

Cuando un loop se porta mal, lo primero que uno hace es culpar al comando. Casi nunca es el comando.

Los loops se rompen de seis maneras, y las seis se arreglan en el mismo lugar: el criterio. Una restricción que faltaba, una orden de enseñar la prueba, un tope. Aquí están los seis, con el síntoma tal como se siente, la causa de verdad y la línea que lo cierra.

Si no tienes claro cuál de los seis te está pasando, no le adivines. Pégale a Claude el criterio tal como lo escribiste y que lo audite causa por causa antes de que le muevas nada. Su lista no es idéntica a la de arriba: aquélla ordena los síntomas, la del prompt ordena las causas.

Tengo un ciclo de verificación que no está funcionando y quiero saber por qué antes de tocarle nada.

Mi criterio es:
[PEGA AQUÍ LA CONDICIÓN O EL CRITERIO TAL CUAL LO ESCRIBISTE]

Lo que está pasando es:
[ELIGE UNA: nunca se da por cumplido y da vueltas de más · se da por cumplido pero el trabajo quedó mal · se detiene antes de tiempo · no sé, solo se siente raro]

Diagnostícalo revisando estas seis causas, una por una, y dime de cada una si aplica o no y por qué:

1. Falta la prueba. ¿Mi criterio le pide a Claude que deje la evidencia escrita en la conversación? Si el comando corrió pero la salida no quedó pegada, quien juzga no vio nada. Esta es la causa más común de los que nunca se cumplen.

2. El criterio es una opinión. ¿Hay algo ahí que dependa del gusto de quien lo lea? Señálame la palabra exacta.

3. Se puede hacer trampa. ¿Existe una forma de cumplir mi criterio al pie de la letra sin hacer el trabajo? Borrar la prueba que falla, meter el resultado a mano, cambiar el número esperado. Enséñame el atajo concreto y la restricción que lo cierra.

4. Son varios criterios disfrazados de uno. ¿Estoy midiendo dos o tres cosas a la vez? Si sí, dime cuál debería ser el estado final y cuáles bajan a ser restricciones.

5. No hay tope. ¿Le puse un límite de vueltas? Si no, propón uno.

6. El costo. Dime cuántas vueltas lleva esto y qué tanto se está gastando, y si el criterio se puede comprobar con un solo comando en vez de con varios.

Al final, entrégame el criterio corregido en una sola línea, lista para copiar, y en dos renglones cuál de las seis causas era la de verdad.

Los seis modos de falla se arreglan reescribiendo el criterio. Los límites de esta última lista no se arreglan: se planean.

Si cierras esta guía y te sientas a montar el estándar completo, los tres cerradores y el hook en la misma tarde, lo más probable es que no termines ninguno de los tres. No armes el sistema. Arma una comprobación.

Uno solo, y de preferencia el más aburrido que tengas. La ruta de abajo es la que recomienda Anthropic y va de menos a más a propósito: cada paso te deja algo funcionando antes de que pases al siguiente, y en dos de ellos la respuesta correcta puede ser que ya terminaste.

Escríbelo solo, sin nada más. Si te contesta con el estado de la meta, ya lo tienes y puedes seguir. Si te dice que no conoce el comando, actualiza Claude Code y vuelve a intentarlo antes de escribir un solo criterio.

El ir y venir no se acaba. Cambia de dueño. Tú sigues poniendo la vara, y esa parte sigue siendo la difícil; lo que dejas de hacer es sostenerla vuelta tras vuelta.

Y la última, tal como la dice Anthropic: corre el loop, observa dónde se atora y dónde se pasa de la raya, y no te dé miedo cambiarlo.