Dejé de negociar con Claude

Estoy a mitad de una feature y se me termina el context window.

Lo que hacía era pedirle a la sesión que se estaba muriendo que me dejara un prompt para la siguiente. "Resumime dónde quedamos así lo pego mañana."

Funciona. Más o menos.

El problema es que ese resumen lo escribe la misma sesión que está por morir, sin ninguna pauta de qué tiene que incluir. Y sin pauta, cada vez incluye cosas distintas. Se acuerda del último archivo que tocamos y se olvida de la decisión que habíamos tomado tres horas antes, esa que veníamos respetando toda la sesión y que nunca llegó a quedar escrita en ningún lado.

Al día siguiente pegaba el prompt y arrancaba la negociación. Claude preguntaba algo que ya habíamos resuelto. Yo aclaraba. Hacía una versión parecida a lo que quería. Yo corregía. Leía tres archivos que no hacía falta que leyera. Recién a la tercera o cuarta vuelta empezábamos a laburar.

Y lo que se había perdido no siempre lo notaba en el momento. A veces me caía dos horas después, cuando algo estaba resuelto distinto a como lo habíamos acordado el día anterior.

Los dos comandos

Lo partí en las dos puntas.

/handoff es el cierre. En vez de pedirle un resumen libre, le digo exactamente qué tiene que quedar escrito y en qué archivos. Desde que lo tengo puedo cortar a mitad de una spec sin miedo: corro /handoff y listo. Si la feature ya está para PR, corro /handoff y /pr.

/cold-start es el arranque, y por dentro es una lista corta. Qué leer y en qué orden: el contexto del repo, el spec con qué features están terminadas y cuál está en vuelo, las dos secciones del PROGRESS.md que importan, el estado de git, y qué evidencia quedó vencida.

Lo que más rinde es la otra mitad: decirle qué no leer. Cuando el PROGRESS.md se hace largo, lo viejo se rota a un archivo aparte. Ese archivo está por si algún día lo necesito, no para leerlo en cada arranque: si Claude lo abre, me come medio context window antes de escribir una línea. Y sin la instrucción explícita, lo abre. Explorar sirve cuando no sabés dónde está la información, y acá yo sí sé.

El formato de salida también está definido ahí adentro, así que la respuesta llega sola: cinco líneas con dónde se frenó, cuál es la próxima acción exacta y qué evidencia venció. Y cierra proponiéndome por dónde arrancar.

Dónde paró: F17 mergeó (PR #88), la fase 3 va 19/28 passing, nada en vuelo,
árbol limpio. La rama feat/serie-a-serie-f18 ya existe con 0 commits propios.

Próxima acción exacta: F18 es test_first, así que arranca por el rojo, no por
el código. Agregar a lib/home.test.ts el caso "dos de cuatro series cargadas no
cuentan el ejercicio como cargado" y correr vitest esperando EXIT 1.

Evidencia vencida: 119 renglones, ninguno de F17 ni F18. Se re-corren, no se
re-hashean.

¿Arranco F18 por el rojo?

Mirá el detalle de la segunda línea. Me recuerda que esa feature arranca por el test que falla y no por la implementación. Eso lo decidí una vez, en frío, y ahora no me lo puedo saltear aunque esté apurado y con ganas de ir directo al código.

Por qué funciona

La idea de ahorrar tokens no va por la longitud del prompt, va por la exactitud. Y eso es justamente lo que te dan los comandos: consistencia y exactitud.

Un prompt inexacto abre conversación. Claude pregunta, yo aclaro, hace algo parecido, yo corrijo. Cada una de esas vueltas se lleva puesto todo el contexto anterior: no pagás el prompt, pagás la conversación entera otra vez, en cada turno. Tres vueltas de negociación salen más caras que la instrucción más larga que puedas escribir.

¿De dónde sale la exactitud? De tres cosas que el comando tiene y el resumen libre no.

Nombra las fuentes. No le pido que se acuerde de dónde quedamos. Le digo de qué archivos sacar el estado y en qué orden leerlos. El estado no lo reconstruye de memoria, lo lee.

Dice qué queda afuera. Sin eso Claude explora, y explorar cuesta context window.

Fija la salida. Le digo exactamente qué formato quiero. Sin eso, cada arranque devuelve un resumen distinto y termino preguntando yo lo que faltó.

El resumen que me dejaba la sesión vieja no tenía nada de eso. Decidía sola qué era importante, y lo decidía en el peor momento, con el context window ya lleno.

El comando sigue siendo un prompt, solo que no lo improvisa nadie a mitad de una feature. Como es exacto, no hay nada que negociar: el primer turno ya es trabajo.

Cómo me doy cuenta de que algo puede ser un comando

Después de estos dos empecé a ver el patrón en otros lados.

La señal más simple: si estás escribiendo el mismo prompt por tercera vez, ya es un comando que todavía no escribiste.

Después le sumé dos preguntas.

¿La respuesta correcta depende de mi criterio o del estado del proyecto? "¿Conviene partir este módulo en dos?" es criterio, y eso no lo voy a poder acotar nunca. "¿Qué quedó desactualizado en el PROGRESS.md?" es estado, y tiene una sola respuesta posible.

¿Puedo enumerar los pasos? Si me siento y escribo la lista de lo que tiene que pasar, en orden, ya está resuelto. Si me trabo enumerando, todavía no entendí bien qué estoy pidiendo, y armar el comando ahí solo congela mi confusión.

El límite

Los comandos son para cómo trabaja el harness, no para qué se construye.

Las decisiones del proyecto quedan afuera. Si esta feature va o no va, cómo modelamos esto, si conviene refactorizar ahora. Ahí quiero criterio, y el criterio no entra en una lista de pasos.

Lo que sí entra es la parte que se repite igual en cada vuelta: cerrar, abrir, dejar los archivos al día, chequear qué venció. Eso no es el trabajo, es la ceremonia alrededor del trabajo. Y la ceremonia conviene tenerla escrita.