El arnés: cuatro agentes y uno que suspende

01 el problema

Lo que pasa cuando le sueltas la mano

Cuando un modelo dice que ha terminado no te está mintiendo. Te está diciendo que ha llegado al final de lo que se propuso hacer. Son cosas distintas, y la diferencia es todo el problema.

Un agente que escribe código tiene una vista parcial de su propio trabajo: recuerda lo que decidió, no lo que quedó. Si le preguntas si está bien, te dirá que sí — no por complacerte, sino porque el único juez disponible es el mismo que hizo el trabajo, y ese juez ya dio el asunto por cerrado cuando escribió la última línea.

Lo caro no es que se equivoque. Lo caro es *cuándo te enteras*. Un fallo que salta al ejecutar cuesta dos minutos. El mismo fallo descubierto tres semanas después, con otras cinco cosas construidas encima, cuesta una tarde entera de arqueología — y a veces cuesta deshacer las cinco.

En este repositorio hay una frase que resume tres meses de esto: *los fallos caros nunca fueron ruidosos, fueron silencios*. Un agente sin arnés produce silencios muy bien redactados.

Las tres formas en que se te va el tiempo

La primera es rehacer. Le pides algo, sale mal, se lo explicas otra vez con más detalle. Cada vuelta cuesta contexto, tokens y paciencia, y ninguna de las tres queda registrada en ningún sitio.

La segunda es revisar. Abres el diff, lo lees entero, y como no sabes dónde mirar lo lees todo con la misma atención. Ahí es donde se va el rato de verdad, y es un rato que no se nota porque parece trabajo.

La tercera es la que no ves: lo que no revisas. Eso no cuesta hoy. Cuesta el mes que viene.

02 la cuenta

Lo que cuesta revisarlo a mano

Antes de montar nada conviene poner el número, porque es el que decide si esto merece la pena para ti. La cuenta tiene tres piezas y ninguna es un porcentaje sacado de internet: son tus tareas, tus vueltas y tu rato.

Cuenta cuántas tareas de verdad le encargas a la semana — no mensajes, tareas con principio y final. Multiplica por las vueltas que suele dar cada una hasta que la das por buena. Y multiplica eso por lo que tardas tú en mirarlo.

Doce horas al mes es media jornada semanal leyendo trabajo ajeno para comprobar algo que un comando puede contestar en cuatro segundos. Y la parte mala de esas doce horas no es el número: es que son horas de atención, la más cara que tienes, gastada en la tarea más mecánica del día.

Y hay un coste que no aparece en la tabla y que probablemente es el mayor: lo que gastas cuando el agente insiste. Un agente sin límite de vueltas puede pasarse la noche reintentando la misma tarea de doce maneras distintas, cada una con el contexto entero cargado. Ese gasto no se nota mientras pasa. Se nota al final de mes.

03 el reparto

Los cuatro agentes, y qué hace cada uno

La parte que suena a exageración y no lo es: no es un Claude haciéndolo todo. Son cuatro papeles distintos, y lo que los hace funcionar es que ninguno puede hacer el trabajo del siguiente.

1 · El que debate el plan

Habla contigo y no escribe una línea de código. Su trabajo es que salga un plan que te convenza, y para eso tiene que llevarte la contraria cuando haga falta. Un plan aceptado a la primera casi siempre es un plan que no se ha entendido.

De aquí sale una lista de tareas, no un documento. Cada una con su qué, su por qué y los ficheros que va a tocar.

2 · El que escribe las fichas

Coge ese plan y lo convierte en fichas, una por fichero, en markdown. El formato importa menos de lo que parece; lo que importa es que cada ficha tenga un final comprobable escrito antes de empezar.

# TNN · Título de una línea
**Estado:** todo · **Vueltas:** 0/3 · **Criterio:** criterios/TNN.sh
**Rama:** tarea/TNN-nombre
**Tipo:** INDEPENDIENTE | DEPENDIENTE
**Depende de:** —
**Para en Javi:** no

## Qué
Una frase. Lo que hay que hacer.

## Por qué
Una frase. Si no la hay, la tarea sobra.

## Ficheros
Los que se van a tocar, listados.

## Hecho cuando
`criterios/TNN.sh` sale 0.

## Mira Javi
Lo que ningún comando puede juzgar. Puede estar vacío.

Fíjate en dos campos. «Por qué», y si no lo hay la tarea sobra: es el filtro más barato que existe contra el trabajo que nadie pidió. Y «Mira Javi», que es donde va lo que un comando no puede decidir — así el criterio no intenta opinar sobre gusto y el gusto no se disfraza de comprobación.

3 · El que ejecuta

Abre una rama, implementa y no toca los criterios. Esa última parte no es una formalidad: si quien implementa puede editar su propio examen, el bucle converge en una semana a *cada tarea aprueba su propio examen*, y entonces tienes un sistema que siempre dice que sí.

4 · El que verifica

Arranca sin el contexto de la conversación, lee la ficha, ejecuta su criterio y mira el código de salida. No lee el diff, no opina y no negocia. Tiene sección propia más abajo, porque es el que cambia el resultado.

04 el inventario

Las piezas, y qué hace cada una

Antes de montarlo conviene ver el inventario, porque ninguna de estas cinco piezas hay que comprarla: cuatro son carpetas y ficheros de texto, y la quinta viene de serie con la herramienta.

• Las carpetas, que son el estado. todo/, en-curso/, hecho/,

atascado/ y javi/. Dónde está una tarea se ve sin abrir nada.

• La ficha, un markdown por tarea con su «hecho cuando» escrito antes de

empezar. Es el contrato.

• El criterio, un script por tarea que sale 0 o distinto de 0. Es el examen,

y se escribe antes que el código.

• Los hashes, un sha256sum de cada criterio congelado. Es lo que impide que

quien implementa retoque su propio examen.

• El verificador sin contexto. Aquí sí hay pieza de producto: se monta con un

subagente, que arranca en su propia ventana de contexto y con sus propios permisos, así que no arrastra la conversación en la que se escribió el código. Si quieres que además sea imposible saltárselo, un hook ejecuta el criterio en un evento del ciclo de vida, y eso ya no depende de que a nadie se le olvide.

Lo demás —el orden, las reglas, el tope de vueltas— es texto en un CLAUDE.md, que es el fichero que la herramienta lee al empezar cada sesión.

05 el tablero

Las carpetas son el estado

Aquí está la parte que menos parece ingeniería y más trabajo hace. El estado de una tarea es la carpeta en la que está. No hay base de datos, no hay campo estado, no hay panel. Una tarea que está en curso vive en en-curso/, y cuando pasa su examen se mueve a hecho/.

tareas/
  todo/         tareas definidas y sin empezar
  en-curso/     la que se está haciendo AHORA · máximo una
  hecho/        pasó su criterio, con su nota de porqué
  atascado/     3 vueltas sin pasar · datada · NO se reintenta sola
  javi/         parada esperando algo que solo puede decidir una persona
  criterios/    el examen de cada tarea · CONGELADO
  informes/     por qué suspendió, uno por vuelta fallida

Que el estado sea una carpeta tiene tres consecuencias buenas y conviene verlas porque son el motivo de que esto no se desincronice.

La primera: no hay dos verdades. Un campo estado en una base de datos y un fichero en una carpeta se separan en cuanto algo se interrumpe. Aquí solo hay una cosa, y es la que ves.

La segunda: sobrevive a un corte. Cierras el portátil a mitad, vuelves tres días después, y el tablero sigue diciendo exactamente lo mismo. No hay que recordar por dónde ibas porque no se recuerda: se recalcula mirando.

La tercera: ls es el panel de control. Cuatro ficheros en todo/, uno en en-curso/, cincuenta y uno en hecho/. Eso se lee de un vistazo y no necesita ninguna aplicación.

javi/ no es atascado/, y separarlas importa

Dos carpetas que parecen la misma y son opuestas. atascado/ es fracaso: tres vueltas sin pasar el criterio. javi/ es lo contrario — no hay nada roto, hay algo que decidir.

Si van juntas, al sentarte ves una sola carpeta de alarma y no distingues «esto se ha roto» de «esto te espera». Son dos lecturas opuestas y dos reacciones opuestas, y mezclarlas hace que dejes de mirar las dos.

06 los límites

Y cuándo no necesitas un arnés

Y hay un caso más en el que sobra: cuando el problema no es de verificación sino de definición. Si no sabes qué quieres, ningún revisor te lo va a decir. Un arnés comprueba que funciona; nunca comprueba que era esto lo que pedías. Esa pregunta sigue siendo tuya, y por eso el criterio se lee antes de que se escriba el código, no después.

Una regla que va con esto y ahorra sustos: la dificultad se aparca y el daño para todo. Si una tarea no pasa tres veces, se aparca y se sigue con la siguiente; nunca se detiene la tirada por una tarea difícil. Pero si han desaparecido ficheros, o hay menos datos que al empezar, o se ha tocado algo fuera del alcance de la ficha, se para todo y se avisa. Seguir mientras nadie mira multiplica el destrozo.

07 el revisor

El cuarto agente: el que no puede negociar

Cuando una tarea termina, no la aprueba quien la hizo. Entra otro agente con tres carencias deliberadas: no ha visto la conversación, no sabe qué se intentaba, y no lee el código de los otros para «entender la intención».

Las tres son intencionadas. Un revisor que conoce la intención perdona: entiende por qué se hizo así, ve el esfuerzo, y acaba aprobando algo que no cumple porque sabe lo difícil que fue. Un revisor que no puede empatizar no puede perdonar, y eso es exactamente lo que se le pide.

Eres el verificador de una tarea. NO la has implementado tú.

Reglas, y no se negocian:
1. Lee SOLO el fichero de la tarea y su criterio.
2. NO leas el diff. NO leas la conversación anterior.
3. Ejecuta el criterio suelto, sin tubería:
     bash tareas/criterios/TNN.sh ; echo "salida: $?"
4. Mira el código de salida. 0 pasa. Cualquier otro suspende.
5. No opines sobre estilo. No propongas mejoras. No negocies.

Si suspende: escribe en informes/ QUÉ comprobación falló y con qué
salida. Nada más. No lo arregles: arreglarlo es de otro.

El criterio de cada tarea es un script que sale 0 o distinto de 0. Nada de «se ve bien». Si algo necesita un ojo humano, va en «Mira Javi» y no en el criterio.

#!/usr/bin/env bash
# T57 · el buscador filtra por dos campos a la vez
set -uo pipefail
cd "$(dirname "$0")/../.." || exit 1

fallos=0
comprueba () {  # descripción  esperado  obtenido
  if [ "$2" = "$3" ]; then echo "  ✓ $1"
  else echo "  ✗ $1 — esperaba «$2», salió «$3»"; fallos=$((fallos+1)); fi
}

# 1 · el módulo importa sin reventar
python3 -c "import app.buscador" 2>/dev/null
comprueba "el módulo importa" "0" "$?"

# 2 · dos filtros a la vez devuelven la intersección
n=$(python3 -c "from app.buscador import buscar; print(len(buscar(tipo='guia', nivel='avanzado')))")
comprueba "filtra por los dos campos" "3" "$n"

exit $fallos

Los hashes, que son la puerta de verdad

Aquí está la pieza que sostiene todo lo demás y que casi nadie pone: los criterios se congelan. Un fichero guarda el sha256 de cada examen, y el verificador los comprueba antes de ejecutar nada. Si uno no cuadra, suspenso automático sin llegar a correrlo.

# congelar (se hace una vez, cuando el criterio está aprobado)
cd tareas/criterios && sha256sum *.sh > HASHES.txt

# comprobar antes de verificar nada
cd tareas/criterios && sha256sum --quiet -c HASHES.txt || {
  echo "✗ un criterio ha cambiado desde que se congeló · SUSPENSO"
  exit 1
}

Sin esa puerta, el bucle converge solo a lo que quieras que diga. Alguien —o algo— ajusta el examen medio grado para que pase, la tarea aprueba, y a partir de ahí el sistema entero está midiendo su propia complacencia. Con la puerta, tocar el examen es un suspenso más ruidoso que no tocarlo.

Y una trampa práctica que cuesta media hora encontrar dos veces: el criterio se ejecuta suelto, nunca por una tubería. bash criterio.sh | tail devuelve el código de salida de tail, no el del criterio. Un examen puede imprimir un error rojo en pantalla y «pasar».

08 antes de nada

Lo que hace falta antes de montarlo

Nada que instalar más allá de lo que ya tienes, pero sí tres cosas que conviene tener antes de empezar, porque sin ellas el tablero se queda en carpetas vacías.

• Un repositorio con git y el árbol limpio: el arnés se apoya en ramas y commits.
• Claude Code funcionando, y la costumbre de encargarle tareas con principio y final.
• sha256sum disponible en el sistema (viene de serie en Linux y macOS).
• La cuenta del apartado uno hecha, y que te salga por encima de tres horas al mes.
• Media tarde para montarlo y una tarea de verdad, aburrida, con la que estrenarlo.

09 manos a la obra

Montarlo desde cero

Lo que sigue es el mínimo que funciona. No hace falta nada más para empezar, y casi todo lo demás se puede añadir después.

mkdir -p tareas/{todo,en-curso,hecho,atascado,javi,criterios,informes}

cat > tareas/verificar.sh <<'FIN'
#!/usr/bin/env bash
set -uo pipefail
cd "$(dirname "$0")/.." || exit 1
C="tareas/criterios"; T="${1:-}"
[ -n "$T" ] || { echo "uso: bash tareas/verificar.sh TNN"; exit 2; }
[ -f "$C/$T.sh" ] || { echo "no existe $C/$T.sh"; exit 2; }

echo "── comprobando que los criterios no se han tocado ──"
(cd "$C" && sha256sum --quiet -c HASHES.txt) || {
  echo "   ✗ UN CRITERIO HA CAMBIADO · SUSPENSO AUTOMÁTICO"; exit 1; }
echo "   ✓ hashes intactos"

bash "$C/$T.sh"; r=$?
[ $r -eq 0 ] && echo "══ $T · APTO" || echo "══ $T · SUSPENDE (salida $r)"
exit $r
FIN
chmod +x tareas/verificar.sh

Y la comprobación, que es lo que separa «ya está montado» de «creo que está montado»: se ejecuta un criterio y se mira lo que contesta.

# se ejecuta suelto y se mira el código de salida, nunca por una tubería
bash tareas/verificar.sh T01
echo "salida: $?"

Así contesta en el repositorio donde escribo esto. Es la salida literal del 5 de septiembre de 2026, sin retocar:

── comprobando que los criterios no se han tocado ──
   ✓ hashes intactos

  ✓ existen tests de la API
  ✓ pytest pasa
  ✓ script typecheck
  ✓ el front compila

══ T01 · APTO (salida 0)

Cuatro comprobaciones y una palabra: APTO. Eso es todo lo que tiene que leer quien supervisa, y es lo que sustituye a los quince minutos de leer un diff.

El criterio se escribe antes que el código y se lee antes de empezar. Ése es el único gate humano del sistema y es innegociable: es el momento en que decides que lo que se va a comprobar es lo que de verdad querías.

Después, el ciclo de una tarea es siempre el mismo. Se comprueba que el árbol está limpio. Se coge una tarea de todo/ y se mueve a en-curso/. Se abre rama. Se implementa sin tocar criterios. Entra el verificador. Pasa a hecho/ con su nota, o sale un informe y vuelve con el contador subido.

El cierre, que es donde se rompe

El paso que más se salta y el que más caro sale: una tarea se cierra antes de empezar la siguiente. Una rama abierta no es un pendiente, es una trampa para la tarea que viene detrás — la siguiente acaba trabajando sobre la rama de la anterior y separarlas después cuesta más que haberlas cerrado.

# 1 · se commitea por RUTAS, nunca con git add -A
git commit -F mensaje.txt -- tareas/todo/T57-x.md tareas/hecho/T57-x.md

# 2 · se COMPRUEBA que el commit existe antes de fusionar
git log --oneline -1

# 3 · y solo entonces se fusiona
git checkout master
git merge --no-ff tarea/T57-x
git branch -d tarea/T57-x

Los tres pasos van sueltos a propósito. Encadenados con &&, un commit que falla corta la cadena pero el merge de la línea siguiente se ejecuta igual y fusiona una rama sin commits: sale «fusionada» en verde, la rama se borra, y el trabajo se queda suelto sin un solo commit. Un mensaje de éxito sobre una fusión vacía es el peor fallo posible, porque no vuelve a aparecer.

10 el bucle

Los encargos, uno por uno

Una aclaración antes de los prompts, porque importa: el arnés no vive en cuatro ficheros de prompt. Vive en las carpetas, en el criterio y en las reglas escritas en el CLAUDE.md del tablero. Lo de abajo es la forma corta de esas reglas, para que puedas pegarlas hoy mismo.

Vamos a decidir qué hay que construir. NO escribas código todavía.

Tu trabajo es que salga un plan que me convenza, no que me des la razón.
- Hazme las preguntas que te falten antes de proponer nada.
- Cuando propongas algo, dime en qué caso concreto es mala idea.
- Si lo que pido es más de lo que hace falta, dilo y recorta.

Cuando el plan esté cerrado, dámelo como LISTA DE TAREAS, no como documento.
Cada tarea: qué se hace, por qué, y qué ficheros toca. Si una tarea no tiene
un "por qué" de una frase, se cae de la lista.

Convierte este plan en fichas, una por tarea, en markdown, dentro de todo/.

Cada ficha lleva, sin excepción:
- Qué (una frase) · Por qué (una frase) · Ficheros que toca
- Hecho cuando: el comando que tiene que salir 0
- Mira Javi: lo que ningún comando puede juzgar (puede quedar vacío)

Y escribe el criterio de cada una ANTES que su código, en criterios/TNN.sh.
El criterio comprueba el resultado, no el método: nada de "existe la función X".
Si no sabes cómo comprobar una tarea, esa tarea todavía no está definida —
dilo en vez de inventarte una comprobación que siempre pasa.

Y el tercero es el que implementa, que no necesita prompt especial: necesita un límite. Uno solo, y es el que sostiene el sistema entero: no toca criterios/. El cuarto, el que verifica, sí tiene encargo propio y va en su sección de más arriba.

11 el material

El tablero mínimo, para llevártelo

Lo que de verdad hace falta copiar no es un script: son las reglas, porque son lo que impide que el bucle se relaje. Esto va en el CLAUDE.md de tu proyecto, o en tareas/CLAUDE.md si prefieres tenerlo aparte.

## Cómo se trabajan las tareas

Las carpetas son el estado:
  todo/       definida, sin empezar
  en-curso/   la única que se está haciendo AHORA (máximo una)
  hecho/      pasó su criterio, con nota de por qué se hizo así
  atascado/   tres vueltas suspendidas, datada, no se reintenta sola
  javi/       parada esperando una decisión que solo puedo tomar yo
  criterios/  el examen de cada tarea, congelado con sha256

Reglas que no se negocian:
1. El criterio se escribe ANTES que el código, y lo leo yo antes de empezar.
2. Quien implementa NO edita criterios/. Nunca.
3. El verificador arranca sin el contexto de la conversación.
4. El criterio se ejecuta suelto, sin tubería, y se mira el código de salida.
5. Tres vueltas suspendidas y la tarea se aparca en atascado/, con fecha.
6. Una tarea se cierra (commit por rutas + merge) antes de empezar la siguiente.
7. La dificultad se aparca y se sigue. El DAÑO para la tirada entera:
   si faltan ficheros o hay menos datos que al empezar, se para y se avisa.

12 la prueba

Lo que llevo cerrado así

En el repositorio donde escribo esto, contado el 5 de septiembre de 2026: hay 50 tareas en hecho/, cada una con su nota de por qué, y 53 exámenes congelados en criterios/ — 54 líneas en HASHES.txt, porque también se congela el fichero común que todos comparten. Quedan 3 en todo/, ninguna en curso, ninguna atascada, y 10 fichas paradas en javi/ esperando una decisión que no puede tomar un comando.

Eso último es la parte que más me sorprendió: el tablero crece porque se cierran tareas. Cada verificación encuentra cosas reales fuera del alcance de su ficha, y en vez de colarlas de propina —que es justo lo que el arnés existe para impedir— se abre ficha nueva. Un tablero que no adelgaza no es un tablero parado.

Un sistema de verificación también se pudre. La comprobación es reejecutar los criterios de todo lo que está en hecho/ y mirar cuántos siguen saliendo 0. Si alguno ha dejado de pasar, no es que el examen esté mal: es que algo que se dio por hecho se rompió después y nadie se enteró.

Esa auditoría no forma parte del bucle a propósito. Es para cuando te sientas y quieres comprobar sin leer un diff ni fiarte de un resumen.

Y una nota real de una tarea cerrada, para que se vea qué se guarda: en la primera del tablero, la ficha decía meter una dependencia en un fichero que no existía, y el fichero equivalente lo copiaba la imagen de producción — meter ahí una herramienta de pruebas la habría mandado al servidor. Se resolvió con un fichero aparte que la imagen no copia, y quedó un test vigilando que nadie lo vuelva a colar. Eso es lo que se pierde cuando solo se registra *qué* se hizo y no *por qué así*.

13 las dos formas

El mismo tablero, según con quién trabajes

El tablero no cambia; cambia quién es el gate humano y qué pasa cuando alguien tiene que decidir. Son dos montajes con la misma pieza.

Y si trabajas para un cliente hay una tercera diferencia que no es técnica: la nota de por qué se hizo así, la que se escribe al pasar a hecho/, deja de ser un lujo. Es lo que puedes enseñar dentro de seis meses cuando alguien pregunte por qué se tomó una decisión que ya nadie recuerda.

14 el calendario

Qué esperar, y cuándo

• La primera tarde. Vas a montar el tablero en un rato y a escribir tu primer

criterio en diez minutos. Lo que cuesta no es eso: es escribirlo antes. La primera vez que te sientas a definir cómo se comprueba algo que aún no existe se te va media hora, y es la media hora que más rinde de todas.

• A las dos semanas. Empiezas a notar que dejas de leer diffs. No porque te

fíes más, sino porque la pregunta ha cambiado: ya no es «¿está bien esto?», es «¿salió 0?». También te va a suspender algo que tú habrías aprobado, y ése es el día en que el arnés empieza a servir.

• Nunca. No esperes que el arnés te diga si era *esto* lo que querías. Un

criterio comprueba que funciona lo que pediste; que fuera lo correcto es una pregunta que sigue siendo tuya, y por eso el criterio se lee antes de escribir el código y no después.

15 el diagnóstico

Cuando el arnés te para

Un arnés que funciona suspende, y los suspensos no son todos iguales. Éstos son los tres que vas a ver, con lo que hay que hacer en cada caso.

Así se ve un suspenso de verdad. Es la salida literal de una tarea que hoy no está implementada todavía, con sus dos comprobaciones en verde y dos en rojo:

── comprobando que los criterios no se han tocado ──
   ✓ hashes intactos

  ✓ propone T62 y su criterio existe
  ✓ la nombra en los descartes
  ✗ la descarta sin decir que le falta el criterio
  ✗ para-javi.sh no ve una ficha con «Para en Javi: sí» fuera de javi/

══ T64 · SUSPENDE (salida 1)

Y así se ve la puerta de los hashes cuando alguien toca un criterio. Esto lo puedes ejecutar tú ahora mismo y ver salir lo mismo: monta un tablero de mentira en una carpeta temporal, lo congela, lo toca y lo vuelve a comprobar.

# un tablero de mentira, para ver la puerta funcionando sin romper el tuyo
mkdir -p /tmp/demo-hashes && cd /tmp/demo-hashes
printf 'echo "el criterio de la tarea 18"\n' > T18.sh
sha256sum T18.sh > HASHES.txt

echo "── comprobando que los criterios no se han tocado ──"
sha256sum --quiet -c HASHES.txt && echo "   ✓ hashes intactos"

echo '# alguien edita su propio examen' >> T18.sh
echo "── y ahora, con el criterio tocado ──"
sha256sum --quiet -c HASHES.txt || echo "   ✗ UN CRITERIO HA CAMBIADO · SUSPENSO AUTOMÁTICO"

── comprobando que los criterios no se han tocado ──
   ✓ hashes intactos
── y ahora, con el criterio tocado ──
T18.sh: La suma no coincide
sha256sum: ATENCIÓN: 1 suma calculada NO coincidió
   ✗ UN CRITERIO HA CAMBIADO · SUSPENSO AUTOMÁTICO

Fíjate en dónde para: no llega a ejecutar el criterio. Primero comprueba que el examen es el que se congeló, y solo entonces lo corre. Sin esa puerta, el bucle converge en una semana a *cada tarea aprueba su propio examen*.

16 la letra pequeña

Lo que un arnés no arregla

No arregla que no sepas qué quieres. Ya está dicho arriba y se repite aquí porque es lo que más caro sale: el criterio comprueba que funciona, nunca que era esto. Si el criterio está mal pensado, el sistema aprueba con entusiasmo algo que no sirve.

No sustituye a leer. Lo que quita son los quince minutos de revisar lo mecánico; no quita el rato de mirar si la decisión fue buena. Por eso existe el campo «Mira Javi» en cada ficha: es el sitio donde vive lo que ningún comando puede juzgar, y si ese campo se queda vacío en todas las tareas, algo se está escondiendo debajo de la alfombra.

Y no es gratis de mantener. Son carpetas, un criterio por tarea y hashes que recongelar cuando un criterio cambia a propósito. Por debajo del volumen de la cuenta del primer apartado, ese mantenimiento es más caro que el problema que resuelve.

17 las dudas

Las preguntas que salen siempre

¿Hacen falta cuatro sesiones abiertas a la vez?

No. Puedes hacerlo con una que cambie de sombrero, siempre que el verificador arranque limpio. Lo que no vale es que el mismo hilo que ha escrito el código se autoevalúe: ahí ya no hay verificación, hay resumen de sí mismo.

¿Y si el criterio está mal escrito?

Pasa, y es sano. La regla es que no lo arregla quien implementa: se dice, se corrige delante del dueño y se vuelve a congelar. Un criterio que se retoca a mitad de la tarea deja de ser un examen y pasa a ser una negociación.

¿Cuánto se tarda en escribir un criterio?

Entre cinco y quince minutos cuando ya le has cogido el aire, y la mayor parte del tiempo se va en decidir qué se comprueba, no en escribirlo. Si tardas mucho más, casi siempre significa que la tarea está mal definida y lo que hay que arreglar es la ficha.

¿Esto no es mucha ceremonia para trabajar solo?

Depende del volumen, y la cuenta del primer apartado lo contesta. Trabajando solo el arnés cambia de función: no es para controlar a nadie, es para que tú dentro de tres semanas puedas fiarte de lo que hizo el de hace tres semanas sin releerlo entero.

¿Sirve para trabajo que no es código?

La parte de las carpetas y las fichas, sí. La del criterio, solo si el resultado se puede comprobar con un comando. Si lo que produces es un texto, lo que tienes es un gate humano con más pasos — y entonces conviene ser honesto y llamarlo así.

18 el cierre

Antes de irte

Un arnés que no puede suspender no es un arnés. Si el sistema que has montado nunca dice que no, no estás verificando: estás generando informes de conformidad.

• Cada tarea tiene un criterio ESCRITO ANTES que el código.
• Los criterios están congelados con sha256 y se comprueban antes de correr.
• Quien implementa NO puede editar criterios/.
• El verificador arranca sin el contexto de la conversación.
• El criterio se ejecuta suelto, nunca por una tubería.
• Hay un tope de vueltas (3) y al llegar PARA y avisa.
• El estado de una tarea es la carpeta donde está.
• javi/ (hay que decidir) va separada de atascado/ (está roto).
• Una tarea se cierra antes de empezar la siguiente.
• Al pasar a hecho/ se escribe POR QUÉ así, no solo qué.

Y si solo te llevas una cosa, que sea ésta: escribe un criterio para tu próxima tarea antes de encargarla. Aunque sea el más tonto posible.

#!/usr/bin/env bash
# El más tonto que sirve: comprueba el RESULTADO, no el método.
fallo=0
ok() { echo "  ✓ $1"; }
no() { echo "  ✗ $1"; fallo=1; }

[ -f el/fichero/que/tenia/que/existir ] \
  && ok "el fichero está" || no "falta el fichero"

npm test --silent >/tmp/t01.log 2>&1 \
  && ok "las pruebas pasan" || { no "las pruebas fallan"; tail -5 /tmp/t01.log; }

exit $fallo

Con eso ya tienes la mitad del arnés: algo que puede decir que no. El resto —las carpetas, los hashes, el verificador sin contexto— es lo que impide que ese «no» se pueda negociar.

Para quién no es esto

No es para ti si le pides a Claude cosas sueltas y cortas: te va a costar más mantener el tablero que hacer el trabajo, y la cuenta del apartado dos te lo dirá en dos minutos. Tampoco es para ti si lo que te falla es saber qué quieres — eso no lo arregla ningún revisor, y ahí lo que toca es bajar un escalón y analizar el proceso antes de automatizarlo.

Y si lo que necesitas es que Claude repita un proceso tuyo de la misma forma cada vez, eso no es un arnés: es una habilidad, y se monta en una tarde.

Las fuentes

Si sigues por aquí

Diseñar tus propias skills de Claude — si lo que quieres es que repita *tu* proceso igual cada vez, empieza por ahí: es la pieza pequeña de esto mismo y cuesta una tarde en vez de media semana.

La misma pregunta en tres Claude — si has llegado hasta aquí y todavía usas solo la ventana del navegador, ese es el salto que hay que dar antes que éste. Un arnés sin sesión de terminal no tiene dónde agarrarse.

Las cuatro piezas que le ponen ojos — el mismo principio aplicado al diseño: darle una forma de comprobar su propio trabajo en vez de fiarte de que salió bien.