01 Dos piezas: el estándar y quién lo cierra
Pides algo, Claude lo entrega, lo revisas, le devuelves correcciones y vuelta a empezar. Eso es un bucle de verificación, solo que el que decide si está terminado eres tú. El problema es que tú no siempre estás, no recuerdas qué revisaste la última vez y tu criterio cambia de un día a otro.
Para automatizarlo necesitas separar dos cosas: el estándar (con qué se mide el trabajo) y el cerrador (quién decide si se cumple o hace falta otra vuelta).
02 Escribe tu estándar
Tu estándar no se inventa: se descubre en lo que ya corriges. Y solo sirve lo que se puede medir sin opinar. Hay cuatro formas de hacerlo: un número (el archivo no pasa de 300 líneas), un recuento que debe ser cero (ningún console.log), una lista que queda vacía (avisos del linter) y un comando que acaba bien o mal (los tests pasan). Lo que dependa del gusto lo sigues revisando tú.
Quiero sacar mi estándar de calidad de lo que ya corrijo, no de lo que creo que me importa. Revisa los últimos 30 commits de este repositorio, sobre todo los que contienen «fix», «arregla» o «ajusta», y los archivos que se modificaron dos veces seguidas. Devuélveme: 1) las correcciones que se repiten, ordenadas por frecuencia, con un ejemplo concreto; 2) cuáles se pueden comprobar con un comando y cuál sería ese comando en este proyecto; 3) cuáles de esas ya cubre algo automático (tests, linter, CI) y cuáles no. No modifiques ningún archivo.| Dónde guardarlo | Qué va ahí | Cuándo se carga |
|---|---|---|
| CLAUDE.md | Hechos cortos que aplican siempre: cómo se ejecutan los tests, qué carpeta no se toca | En cada sesión, entero |
| Skill de verificación (.claude/skills/) | Procedimientos con pasos: qué comprobar, con qué comando y qué resultado cuenta como aprobado | Solo cuando se usa |
Escríbeme una skill de verificación para este proyecto. Primero hazme estas preguntas de una en una: qué tipo de cambio vamos a verificar, qué reviso hoy a mano y en qué orden, qué parte se puede comprobar con un comando, qué es lo que más se me cuela roto y qué no se debe tocar. Después crea .claude/skills/verificar-[nombre]/SKILL.md con: name, una description que diga cuándo usarla, y pasos numerados donde cada paso indique qué comprobar, el comando exacto, el resultado que cuenta como aprobado y la instrucción «pega la salida del comando en la conversación». Termina con un paso que repita la lista marcando cada punto y declare como «no comprobado» lo que no hayas podido verificar.03 La regla clave: si no se ve en la conversación, no cuenta
Cuando usas /goal, al final de cada turno un modelo pequeño y rápido decide si la condición se cumple. Ese evaluador no abre archivos ni ejecuta comandos: solo lee lo que Claude ha dejado escrito en la conversación. Por eso «que quede bien» nunca se cumple de forma fiable, y «ejecuta los tests y muestra la salida» sí.
| Criterio débil | Criterio verificable |
|---|---|
| Que los tests pasen | npm test termina con código 0 y la salida aparece en la conversación |
| Que el archivo no sea muy largo | wc -l de src/app.ts muestra menos de 300 líneas |
| Sin errores de tipos | npx tsc --noEmit no imprime ningún error |
| No tocar otras cosas | git diff --stat solo muestra archivos dentro de src/auth/ |
04 Quién cierra el bucle
| Cerrador | El siguiente turno empieza | Se detiene cuando |
|---|---|---|
| Tú | Cuando escribes | Decides que está bien |
| /goal | Al terminar el turno anterior | El evaluador confirma la condición o la juzga imposible |
| /loop | Cada cierto intervalo | Lo paras o Claude decide que ha terminado |
| Hook Stop | Al terminar el turno anterior, en todas las sesiones | Tu script o prompt lo decide |
/goal npm test termina con código 0, npx tsc --noEmit no muestra errores y git diff --stat solo incluye archivos de src/auth/. Pega la salida de los tres comandos. O detente tras 15 turnos.
/loop 30m ejecuta la skill verificar-web y corrige lo que falleCombínalos en orden: /goal para llegar al estándar y, una vez alcanzado, /loop para mantenerlo mientras se sigue trabajando. Para que las vueltas de /goal avancen sin pedirte permiso en cada comando, úsalo en modo automático. Con /goal sin argumentos ves el estado y con /goal clear lo cancelas.
05 El cerrador permanente: un hook Stop
/goal dura solo la sesión. Si quieres que el estándar se compruebe siempre en un proyecto, usa un hook Stop en .claude/settings.json. Un hook de tipo prompt evalúa la conversación, igual que /goal. Un hook de tipo agent lanza un subagente que puede leer y buscar en tus archivos antes de decidir, lo que cubre el punto ciego del evaluador. Los hooks de agente son experimentales; para algo crítico en producción, la documentación recomienda hooks de tipo command con un script.
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "agent",
"prompt": "Comprueba que la suite de tests pasa y que no quedan console.log en src/. Si algo falla, explica qué y dónde. $ARGUMENTS",
"timeout": 120
}
]
}
]
}
}06 Cuando el bucle no termina o termina en falso
- ✓Nunca se cumple: el criterio depende de algo que no aparece en la conversación. Exige pegar la salida del comando.
- ✓Se cumple en falso: el criterio es vago y el evaluador lo da por bueno. Sustituye adjetivos por números o comandos.
- ✓Claude «arregla» quitando tests: añade como restricción que ningún archivo de test se modifique.
- ✓Da vueltas sin avanzar: Claude Code lo detecta y te devuelve el control; divide la meta en partes.
- ✓Gasta demasiado: añade un límite de turnos o tiempo a la condición.
- ✓Se para por permisos: ejecuta el bucle en modo automático o añade reglas allow para los comandos de comprobación.
Mi /goal no se cierra (o se cierra antes de tiempo). Esta es la condición: «[pega tu condición]». Analízala: ¿qué partes no puede comprobar un evaluador que solo lee la conversación? ¿Qué partes son subjetivas? Reescríbela para que cada requisito se demuestre con la salida de un comando y añade un límite de turnos.Preguntas frecuentes
Usa el modelo pequeño y rápido configurado en Claude Code, y según la documentación su coste suele ser despreciable frente al trabajo principal.
Sí: también en modo no interactivo con claude -p, en la app de escritorio y mediante Remote Control.
Los bucles con intervalo fijo siguen hasta que los cancelas o pasan siete días. En los que marca Claude, puedes pararlos con Esc.
Sí, siempre que el resultado se pueda comprobar: recuentos de palabras, enlaces rotos, campos obligatorios en un documento o una lista de pendientes vacía.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.