Registro de solicitudes de Claude Code

Me ha pasado más de una vez: por la tarde el equipo y yo probamos varias versiones de un bloque, y a la mañana siguiente alguien pregunta por qué el título quedó más corto. En el chat hay decenas de mensajes, en la memoria queda algo como "creo que el fondo era claro", y la decisión exacta se diluye entre los cambios.

En esos momentos lo que salva la situación es requests.log. Es un rastro externo y breve del trabajo, que se puede abrir en cualquier editor y leer de arriba abajo. No lo valoro por el número de líneas, sino porque permite relacionar una solicitud con lo que de verdad se decidió conservar.

Para qué sirve un rastro externo

Con los años me he acostumbrado a separar cuatro cosas: la solicitud, la decisión, la conversación y la versión guardada del archivo. Responden a preguntas distintas, aunque durante una misma sesión se mezclan con facilidad en una historia confusa.

El registro funciona como un índice: le devuelve al momento adecuado y a las palabras exactas. El código en sí no lo recupera. Si necesita ver la versión guardada de la página, consulte los archivos y el historial de versiones del proyecto.

El esquema muestra bien una diferencia que importa al analizar el log. La cadena de arriba representa el curso del trabajo; la de abajo, lo que queda en el registro. La línea automática aparece antes del resultado, y la nota de decisión, solo después de la revisión. Una no sustituye a la otra.

De qué se compone una entrada útil

Lo mostraré con tres variantes de entrada. En proyectos reales me he encontrado con cada una de ellas.

listo

Esta línea casi no sirve: no queda claro quién hizo qué, cuándo, ni a qué tarea se refiere ese "listo".

Usuario: Haz más corto el título de la tarjeta...
Claude: De acuerdo, primero reviso el componente...
Usuario: Y reduce el margen...
Claude: Corregido...

Aquí, en cambio, ya hay demasiado para una búsqueda rápida. El flujo completo está bien en el historial de la conversación, pero un registro aparte se convierte pronto en una copia incómoda de ese historial. Lo intenté así, y luego yo mismo perdía tiempo desplazándome por el archivo.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Acorta el título de la tarjeta a una sola línea"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Aceptado el título corto, tamaño 24 px"

La tercera variante es la que más me gusta: conserva un hecho breve, la hora con zona horaria, el autor y la etiqueta ref, que enlaza las líneas. Los nombres de los campos se inventaron para un proyecto de práctica. Es el formato de nuestro archivo, no un esquema obligatorio de Claude Code. En este análisis las etiquetas ref se añadieron a mano a las líneas relacionadas. El hook no adivina a qué bloque se refiere la solicitud: el evento básico UserPromptSubmit no incluye una etiqueta semántica de ese tipo. Si no hay campo de enlace, en su registro igualmente se puede buscar por la frase exacta.

Qué se sabía en el momento de la entrada

La línea prompt_submitted dice exactamente una cosa: a la sesión llegó esa petición y el hook la registró. Normalmente es su texto, pero no siempre. UserPromptSubmit se dispara también con cada nueva vuelta de /loop, con el informe de un subagente en segundo plano y con un mensaje de otra sesión, así que actor=user en nuestro formato es una suposición del ejemplo didáctico. De esa línea no se deduce que Claude Code haya cambiado la página, que la revisión haya pasado ni que el resultado le haya gustado a todo el mundo.

Conviene registrar el resultado cuando ya se conoce. En nuestro ejemplo es una nota aparte, añadida después de ver la página. Si su formato tiene campos result o error, rellénelos con hechos observados, no con suposiciones sobre cómo terminará la tarea.

Dónde anotar la decisión tomada

Una decisión existe solo cuando alguien la ha dejado anotada de forma explícita. En el ejemplo de arriba, la línea la añadió el usuario después de ver la página. El autor figura en actor, y el enlace con la solicitud lo guarda ref=card-header.

La nota puede ser manual, y no pasa nada. La entrada automática guarda lo que se envió, y una persona confirma el sentido del resultado. De una línea "listo" sin autor ni vínculo mejor no fiarse.

Leer el registro de solicitudes

Analicemos un registro pequeño de cinco líneas. Precisamente con fragmentos cortos como este suelo empezar cuando hay que reconstruir cómo se llegó a una decisión.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Acorta el título de la tarjeta a una sola línea"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="Muestra dos variantes: 24 px y 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Aceptado el título corto, tamaño 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Haz más suave la sombra de la tarjeta"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Prueba un color más oscuro para el título"

Imagine que necesita encontrar la última decisión tomada sobre el formato del título. Empiece buscando card-header en el editor. Salen cuatro líneas. La última contiene una nueva petición sobre el color, pero no una decisión. Por eso la conclusión se apoya en la línea de las 14:41:06: se aceptó el título corto con un tamaño de 24 px.

Mi orden de lectura habitual es sencillo:

1. Primero formulo la pregunta: busco una solicitud, una decisión o un error observado.
2. Encuentro la etiqueta común, el nombre del componente o la frase exacta.
3. Me quedo con las entradas del tipo que necesito y las leo en orden cronológico.
4. Nombro las líneas que confirman la conclusión. Todo lo demás lo dejo, con honestidad, como desconocido.

Este análisis se puede hacer incluso sin ejecutar Claude Code. Es un hábito útil: primero contrastar usted mismo la conclusión con el archivo, y solo después encargarle el mismo trabajo al agente.

Cuando en el registro no hay decisión

Ahora quitemos la línea de las 14:41:06. Quedan la petición de mostrar dos tamaños y otra posterior para cambiar el color. ¿Qué tamaño se aceptó? El registro no lo dice.

En casos así dan muchas ganas de elegir 24 px, porque es la primera opción propuesta. Mejor no hacerlo. La solicitud muestra la intención de probar variantes, no el resultado de la elección. Aquí la única conclusión honesta es esta: la decisión sobre el tamaño no está registrada en el log.

La bifurcación no depende del orden de las peticiones, sino del tipo de entrada encontrada. Si hay una nota explícita de decisión, la conclusión se puede confirmar. Si solo quedan solicitudes, dejamos constancia de lo desconocido y no rellenamos el hueco con una suposición. Esta contención, al final, ahorra mucho tiempo.

Qué dejar fuera del log

No intento convertir un registro útil en un almacén de todo lo que pase. Lo que incluye cada entrada conviene elegirlo en función de la pregunta que luego habrá que responder. Para buscar decisiones suele bastar con la hora, el tipo de evento, el autor, la etiqueta de enlace y un texto breve.

• No copie claves, tokens, el contenido de .env ni datos personales.
• No traslade completas las respuestas de servicios externos si solo necesita el estado o el identificador de la operación.
• Deje el prompt completo solo donde de verdad haga falta. En este artículo aparece completo únicamente porque el ejemplo es ficticio y corto.
• Revise de vez en cuando el tamaño del archivo y la utilidad de las entradas antiguas. No existe un plazo de conservación único para todos los proyectos.

Recortar la línea a cien caracteres mejora la legibilidad, pero no elimina los secretos de forma automática. Un token corto cabe perfectamente en los primeros cien caracteres. Primero decida qué datos es admisible registrar. Hay que empezar precisamente por esa regla, no por la longitud de la línea.

Cómo analizar el registro junto con Claude Code

Claude Code arma bien una secuencia temporal y encuentra rápido las líneas relacionadas. Pero para eso tiene que leer el archivo de forma explícita: que requests.log esté en el proyecto no significa por sí solo que su contenido ya esté en el contexto.

Dele al agente una tarea concreta:

Lee requests.log. Encuentra la última decisión aceptada de forma explícita
sobre el tamaño del título de la tarjeta (card-header). Indica las entradas en las que te basas.
Si en el registro solo hay una petición, dilo tal cual.
Enumera aparte lo que sigue siendo desconocido.

Una buena respuesta separará los hechos de la conclusión: citará la hora, el tipo de evento y el texto de la decisión, y luego enumerará las preguntas sin confirmar. Contraste esas referencias con las líneas originales. El error salta especialmente a la vista cuando el agente llama a la última petición "la opción aceptada".

Para el registro de práctica actual, la respuesta será esta: la decisión sobre el tamaño la confirma la entrada 2026-09-08T14:41:06+03:00; más tarde apareció una solicitud de un color más oscuro, pero la decisión aceptada sobre el color se desconoce. Una respuesta así es la que considero fiable: no promete más de lo que hay en el archivo.

• El hook guarda la solicitud antes de que se procese, así que esa entrada no confirma el resultado.
• Una nota aparte vincula la decisión tomada con la solicitud por la hora o por la etiqueta.
• La búsqueda empieza con una pregunta concreta y termina con una referencia a las líneas originales.
• Si no hay confirmación, el registro deja un hueco. No hay que rellenarlo con invenciones.

Así requests.log sigue siendo un pequeño rastro de trabajo: ayuda a encontrar el giro de la discusión que se busca, pero no finge ser ni una copia de seguridad del proyecto ni la prueba de que la tarea está terminada. Cuando el log está hecho con honestidad, de verdad dan ganas de volver a él.