01 El problema: lo que se pierde al cerrar
El código sigue en el disco cuando vuelves al día siguiente. Lo que desaparece es el contexto: por qué se hizo así, qué se descartó y, sobre todo, qué se intentó y no funcionó. Sin eso, Claude propone con entusiasmo la misma solución que ayer os costó dos horas, o toca un archivo que ya estaba bien porque nadie le dijo que no lo tocara.
El resumen automático de la conversación no lo resuelve: decide por su cuenta qué era importante y suele tirar justo los callejones sin salida. Lo que necesitas no es un resumen, sino un archivo de estado del proyecto, corto, con secciones fijas y que puedas abrir y corregir tú.
Sin archivo
Dedicas veinte minutos a contar la historia, olvidas la mitad y Claude rellena huecos con suposiciones.
Con archivo
La sesión arranca sabiendo el objetivo, el punto exacto y la lista de lo que no hay que volver a probar.
02 La estructura del archivo
Guárdalo en la raíz del proyecto, junto al CLAUDE.md. Mantén los encabezados siempre iguales: las reglas y el comando que verás después los usan como referencia. La sección clave es la de descartado, con fecha y motivo de cada intento fallido.
# Blueprint: <proyecto>
Actualizado: AAAA-MM-DD HH:MM
## Objetivo
<una o dos frases con el resultado que buscas>
## Estado actual
<qué funciona, qué está a medias, qué falta probar>
## Archivos implicados
- ruta/archivo.ext: para qué sirve
## Cambios pendientes de commit
- <cambio y motivo>
## Descartado (no repetir)
- [AAAA-MM-DD] Intenté <qué> para <objetivo>; falló porque <causa>.
## Próximos pasos
1. <acción concreta sobre un archivo concreto>| Sección | Qué incluir | Qué evitar |
|---|---|---|
| Objetivo | El resultado, con tus palabras | El plan técnico, que cambia cada semana |
| Estado actual | Una foto de hoy | La crónica de cómo llegaste |
| Archivos implicados | Rutas con una línea de propósito | El árbol completo del proyecto |
| Cambios pendientes | Lo que aún no está en git | Lo que el historial de git ya cuenta |
| Descartado | Qué, para qué y por qué falló, con fecha | «No funcionó» sin motivo |
| Próximos pasos | Un máximo de cinco, cada uno con su archivo | Ideas para algún día |
03 Empieza a mano: dos prompts
Antes de automatizar nada, esto ya funciona: pides el archivo antes de irte, limpias la conversación con /clear y al día siguiente le pides que lo lea. El archivo está en el disco, así que no se pierde al cerrar.
Vamos a parar por hoy. Actualiza blueprint.md en la raíz del proyecto. Si ya existe, léelo entero y reescríbelo completo; no añadas al final.
- Objetivo: déjalo igual salvo que haya cambiado.
- Estado actual: qué funciona, qué está a medias y qué queda por probar.
- Archivos implicados: los de hoy y los de mañana, una línea cada uno.
- Cambios pendientes: solo lo que no esté en git.
- Descartado: todo lo que hoy no ha funcionado, con el formato [fecha] Intenté <qué> para <objetivo>; falló porque <causa>.
- Próximos pasos: máximo cinco, cada uno con su archivo.
Actualiza la fecha y dime en una línea qué has cambiado y cuántas líneas tiene.Lee blueprint.md y todavía no hagas nada más. Resúmeme en cinco líneas el objetivo, dónde nos quedamos, qué archivos están en juego, qué no debemos repetir y cuál es el siguiente paso. Después espera a que te diga por dónde empezamos.04 Que se cargue solo: el import con @
Escribir en el CLAUDE.md «lee blueprint.md» deja una instrucción que a veces se cumple y a veces no. Un import con arroba, en cambio, expande el archivo y lo mete en contexto al arrancar la sesión, igual que el propio CLAUDE.md.
@blueprint.md- ✓La ruta es relativa al archivo que contiene el import, no a la carpeta desde la que trabajas.
- ✓No la pongas entre comillas invertidas ni dentro de un bloque de código: ahí se trata como texto y no importa nada.
- ✓Si el archivo queda fuera del directorio de trabajo, Claude Code pide aprobación la primera vez; si la rechazas, no se carga.
- ✓Los imports encadenados admiten como máximo cuatro saltos.
- ✓Comprueba que funciona con /context: blueprint.md debe aparecer entre los archivos de memoria cargados.
- ✓Lo importado consume contexto en cada arranque, así que mantén el archivo corto.
05 Que se actualice solo: reglas y comando
Para que no dependa de tu memoria, añade al CLAUDE.md unas reglas que indiquen cuándo reescribir el archivo. Ten en cuenta que el CLAUDE.md es contexto, no una configuración obligatoria: se cumple casi siempre, y lo primero que se relaja son las sesiones muy largas. Por eso conviene tener también un comando que lances tú.
## Mantenimiento de blueprint.md
Reescribe blueprint.md completo (nunca añadas al final) cuando:
- Diga que cerramos, que lo dejamos por hoy o ejecute /clear.
- Algo que hemos probado falle: anótalo al momento en «Descartado» con fecha y causa.
- Completemos un próximo paso: quítalo de la lista.
- Cambie el objetivo: mueve el archivo actual a docs/blueprints/ y crea uno nuevo.
Actualiza siempre la fecha y mantenlo por debajo de 120 líneas.---
name: blueprint
description: Actualiza blueprint.md en la raíz del proyecto con el objetivo, el estado actual, los archivos implicados, los cambios pendientes, lo descartado y los próximos pasos. Úsala cuando el usuario escriba /blueprint, diga que cierra la sesión o que algo no ha funcionado.
---
1. Si blueprint.md no existe, créalo con la plantilla del proyecto.
2. Si existe, léelo entero y reescríbelo completo.
3. Registra cada intento fallido con fecha y causa en «Descartado».
4. Aplica la poda antes de guardar y mantén el archivo por debajo de 120 líneas.
5. Responde en una línea qué ha cambiado y cuántas líneas tiene.06 La poda: un archivo que solo crece no sirve
- ✓Fija un techo (por ejemplo, 120 líneas) y recorta primero «Cambios pendientes», luego «Estado actual».
- ✓Saca de «Cambios pendientes» todo lo que ya esté en un commit.
- ✓Retira de «Descartado» los intentos que ya no aplican porque cambió el enfoque o la dependencia.
- ✓Cuando termine la tarea, archiva el blueprint y empieza uno nuevo; no es un diario del proyecto.
- ✓Si la fecha de «Actualizado» es antigua y has trabajado ayer, el archivo está muerto: no te fíes de él.
| Herramienta | Para qué sirve |
|---|---|
| blueprint.md | Retomar una tarea concreta entre sesiones |
| /compact | Liberar contexto dentro de la misma sesión |
| Memoria automática | Preferencias y correcciones que Claude aprende con el tiempo |
| Skill handoff (mattpocock/skills) | Traspasar una conversación a otro agente |
Preguntas frecuentes
Cubren cosas distintas. La memoria automática guarda preferencias y aprendizajes generales; blueprint.md guarda el estado de una tarea concreta y los intentos fallidos, y puedes leerlo y corregirlo tú.
Depende. Si trabajas solo, puede ir en .gitignore. En equipo, cada persona puede tener el suyo, o se comparte uno por rama si la tarea es común.
Ejecuta /context al inicio de la sesión y busca blueprint.md en la lista de archivos de memoria. Si no aparece, revisa la ruta del import y que no esté entre comillas invertidas.
No es su objetivo. Este archivo guarda dónde te quedaste en algo que ya estás construyendo; para diseñar un proyecto desde cero necesitas un documento de especificación.
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.