Sistema de memoria (memory): Haz que te recuerde entre sesiones

📚 Navegación de la serie: En el artículo anterior 24 Plugins (Complementos) aprendimos a empaquetar una serie de configuraciones sueltas en un plugin para instalarlas y detenerlas con un clic. En este vamos a hablar de algo más fundamental: cómo lograr que Claude te recuerde entre una sesión y otra. No solo a través del CLAUDE.md que tú escribes, sino también mediante ese "cuaderno de notas privado" que va rellenando él solo cuando trabaja, en el que anota silenciosamente tus correcciones para recordarlas automáticamente la próxima vez.

Primero hablemos de un error en el que suelen caer muy fácilmente los principiantes.

Cuando descubres la función de "hacer que Claude recuerde cosas", es muy fácil emocionarse y empezar a meter de todo ahí: que si hoy he configurado este puerto, lo meto; que si he cambiado el nombre de una variable temporal, lo meto; e incluso cosas de un solo uso como "esta vez usa el 8081 en lugar del 8080". La lógica detrás de esto suele ser "cuanto más recuerde, más inteligente será".

¿El resultado? Abres el proyecto dos semanas después y empieza a mencionarte el puerto 8081 que descartaste hace siglos, y unas cuantas "preferencias" que ni tú mismo recuerdas por qué escribiste. Se ha llenado la cabeza de cosas inútiles y lo realmente importante ha quedado enterrado.

Ahí es cuando entiendes que: con la memoria no se trata de "cuanto más mejor", sino de "recordar con precisión lo que toca y no tocar lo que no toca". Recordar mal es peor que no recordar: usará información obsoleta para guiarte por el mal camino con total seguridad.

En el artículo 18 Guía de uso de CLAUDE.md explicamos en detalle cómo escribir el CLAUDE.md, y en el 19 Gestión de contexto repetimos que "la memoria automática consume contexto". Pero cómo encajan estas dos piezas para formar un "sistema de memoria" completo, y cómo funciona exactamente ese cuaderno que Claude escribe por sí mismo, es algo que no habíamos explorado a fondo. Hoy lo haremos.

Al terminar este artículo, sabrás:

• Que la memoria de Claude Code se divide en dos sistemas: tu CLAUDE.md vs. su "memoria automática". Una tabla para ver qué hace cada uno.
• En qué archivo se guarda la "memoria automática", cómo se carga en el contexto y cómo usar /memory para auditarla, modificarla o borrarla.
• Cómo hacer que recuerde algo, dónde termina guardado, y cómo se activa automáticamente la próxima vez, paso a paso.
• Una lista de "lo que hay que recordar vs. lo que no hay que recordar", para evitar la trampa de "meter de todo".
• Si el antiguo atajo # sigue funcionando, y cuál es el método oficial actual.

---

01 Primero hay que diferenciar: la memoria son en realidad dos sistemas, no uno

La conclusión por delante: La "memoria" de Claude Code son dos sistemas paralelos, uno que escribes tú y otro que escribe él, cada uno a lo suyo. Mucha gente, cuando piensa en "memoria", solo piensa en CLAUDE.md, pero eso es solo la mitad de la película.

Analogía: Las notas adhesivas en el borde de la pantalla. Tienes dos tipos de papeles en tu mesa. Uno es el "reglamento de trabajo" que has impreso y chincheteado en la pared: las reglas del proyecto, el proceso de commits, todo muy formal y obligatorio para cualquiera. Eso es el CLAUDE.md. El otro es un post-it amarillo que escribes a mano y pegas en el marco del monitor: "el bug de la última vez era por no borrar la caché", para acordarte de un vistazo la próxima vez. Estas notas rápidas que va apuntando sobre la marcha son la "memoria automática (auto-memory)". Los dos están frente a ti, pero uno es "las reglas que yo impongo" y el otro "los aprendizajes que anoto".

La documentación oficial explica muy bien la división del trabajo, aquí tienes una tabla comparativa — esta es la que más te interesa recordar:

Dimensión	Archivo CLAUDE.md	Memoria automática (auto-memory)
Quién lo escribe	Tú (manualmente)	Claude (por sí mismo)
Qué contiene	Instrucciones y reglas	Experiencias y patrones que ha aprendido
Contenido típico	Estándares de código, flujos de trabajo, arquitectura	Comandos de build, consejos de depuración, tus preferencias que él descubre
Cuándo se carga	En cada sesión, carga completa	En cada sesión, pero solo carga las primeras 200 líneas o 25KB
Ámbito	Nivel de usuario / proyecto / local	Una copia por repositorio git (compartida por todos los worktrees)

¿Ves la diferencia clave? El CLAUDE.md es "cómo quieres que lo haga", la memoria automática es "cómo ha descubierto él mismo que se hace". Si le corriges y le dices "en este proyecto hay que levantar el Redis local para los tests", se acordará la próxima vez; y no te ha hecho falta escribirlo a mano en ningún archivo, lo guarda él solo.

También hay otra regla fundamental que la documentación oficial enfatiza y debes asimilar:

Claude trata esto como contexto, no como una configuración obligatoria. Para bloquear una acción, independientemente de lo que decida Claude, utiliza el hook PreToolUse.

¿Qué quiere decir esto? La memoria (la que sea) es solo una sugerencia suave de "lo que le gustaría hacer", no una restricción rígida de "lo que tiene permitido hacer". Esto va muy en la línea de lo que vimos en 20 Configuración de permisos: si realmente quieres prohibir algo, tienes que usar reglas de permisos o hooks. Poner "no hagas push" en la memoria no lo detendrá. La memoria sirve para "que te entienda mejor", no para "vigilarle".

💡 Resumen en una frase: La memoria se divide en dos: CLAUDE.md para las reglas que tú escribes, y la memoria automática para las notas que él toma; ambas son solo sugerencias, si quieres bloquear acciones necesitas permisos o hooks, no basta con escribirlo en la memoria.

Esta imagen muestra los dos caminos de la memoria en paralelo: a la izquierda, el CLAUDE.md (las reglas del proyecto) que tú escribes y que se carga entero en el contexto; a la derecha, la memoria automática (sus notas privadas) que Claude va apuntando en MEMORY.md y de la que solo lee las primeras 200 líneas en cada sesión nueva. Ambas confluyen en la "ventana de contexto de la nueva sesión", para que empiece a trabajar "acordándose de ti".

---

02 El lugar de CLAUDE.md en el sistema de memoria

Ya explicamos a fondo cómo escribir el CLAUDE.md en el artículo 18, así que aquí solo añadiremos su rol dentro del "sistema de memoria": Es ese "reglamento formal" impreso y clavado a la pared que todos tienen que leer.

Analogía: Volviendo a los papeles junto al monitor, el CLAUDE.md es el que está clavado. No es un post-it, es un reglamento formal impreso con chinchetas. Por eso tiene características totalmente distintas a la memoria automática: lo escribes tú, se sube al control de versiones para compartirlo con el equipo, se carga por completo en cada sesión, y su contenido son "reglas", no "experiencias".

Oficialmente, el CLAUDE.md tiene una jerarquía clara por orden de carga (de lo más general a lo más específico):

Nivel	Ubicación	A quién aplica
Políticas administradas	macOS: /Library/Application Support/ClaudeCode/CLAUDE.md Linux/WSL: /etc/claude-code/CLAUDE.md	Desplegado por IT corporativo, los usuarios normales no lo tocan
Usuario	~/.claude/CLAUDE.md	Tus preferencias personales para todos tus proyectos
Proyecto	./CLAUDE.md o ./.claude/CLAUDE.md	Este proyecto, compartido con el equipo (entra en git)
Local	./CLAUDE.local.md	Este proyecto, solo para ti (entra en .gitignore)

Aquí hay una diferencia clave con la memoria automática, que los novatos deben grabarse a fuego:

El CLAUDE.md se carga completo, sin importar su longitud; la memoria automática tiene un límite. La documentación oficial es explícita: "El archivo CLAUDE.md se carga en su totalidad independientemente de su longitud". Por eso en el artículo [18] insistimos en que lo mantengas por debajo de las 200 líneas: no es que no se pueda cargar más, es que cuanto más largo sea, más contexto ocupa y paradójicamente, menos caso le hace. La memoria automática funciona al revés, tiene un límite duro (lo vemos en la siguiente sección) y lo que sobra no se carga.

En la práctica la división es muy clara: "Esto es una regla estricta que tú impones", al CLAUDE.md; "Esto es algo que debe ir aprendiendo y acumulando él solo", a la memoria automática. Por ejemplo, "Usa solo pnpm para dependencias" es una regla inamovible que escribes a mano en el CLAUDE.md; "Los tests de este proyecto necesitan iniciar Redis" es algo que puede descubrir él solo, no hace falta que lo escribas, corrígele una vez y deja que se acuerde.

💡 Resumen en una frase: CLAUDE.md es el "reglamento formal" del sistema de memoria: lo escribes tú, se comparte con el equipo, se carga entero y contiene reglas; tiene un enfoque completamente distinto a las "notas informales" de la memoria automática.

---

03 Memoria automática: el cuaderno de notas que escribe por su cuenta

Llegamos a la parte importante, el tema principal que habíamos pospuesto desde el artículo [18]: la memoria automática (auto-memory), ese cuaderno de notas que Claude escribe para sí mismo.

ℹ️ La memoria automática requiere Claude Code v2.1.59 o superior, y viene activada por defecto. Escribe claude --version para ver qué versión tienes; si es muy vieja, actualízala (ver 02 Instalación).

Analogía: El compañero veterano con el que llevas tiempo trabajando. Un compañero con el que ya tienes rodaje no necesita que le expliques las cosas mil veces: él mismo se ha ido apuntando mentalmente que "en este proyecto se compila con make build y no con npm build", o que "el bug raro de la semana pasada era por no configurar la zona horaria". A la próxima, ya se acuerda. No tienes que explicárselo, él aprende sobre la marcha: eso es el "aprendizaje activo" de la memoria automática de Claude.

¿Qué anota exactamente? La lista oficial: comandos de build, observaciones de depuración, notas de arquitectura, preferencias de estilo de código, hábitos de tu flujo de trabajo. Presta atención a una decisión clave de diseño: no guarda cosas en cada sesión, sino que "evalúa si la información será útil para conversaciones futuras antes de decidir guardarla". Esas tareas puntuales y descartables normalmente no las guarda (lo que ayuda a curar la manía de "meter de todo").

¿Y cómo se guarda esa información en la práctica? Hay dos formas:

La primera, se lo dices directamente. En medio de una charla le dices "a partir de ahora usa pnpm, no npm en este proyecto" o "recuerda que los tests de la API necesitan un Redis local", y él guarda eso en la memoria automática. La cita oficial:

Cuando pides a Claude que recuerde algo, como "utiliza siempre pnpm, no npm" o "recuerda que las pruebas de la API requieren una instancia local de Redis", Claude lo guarda en la memoria automática.

La segunda, aprende él solo de tus correcciones. No tienes que decirle explícitamente "recuerda esto". Si usa npm test y tú le dices "en este proyecto usamos pnpm test", si juzga que es útil para el futuro, lo apuntará. Esta es la parte más útil de la memoria automática: tú trabajas y le corriges con normalidad, y él va acumulando conocimientos por detrás, sin que tengas que hacer ningún esfuerzo extra.

¿Cómo sabes si está anotando algo? Por los mensajes de la interfaz. La documentación indica que si ves "Writing memory" o "Recalled memory" en la pantalla de Claude Code, es que está escribiendo en su cuaderno o leyendo de él.

💡 Resumen en una frase: La memoria automática son las notas adhesivas que Claude se escribe para sí mismo: se lo pides tú o lo aprende de tus correcciones, y solo guarda lo que cree que "será útil en el futuro"; los mensajes "Writing/Recalled memory" te avisan de que está apuntando o consultando notas.

---

04 Dónde se guarda y cómo se carga en el contexto

Esta sección resuelve dos de las dudas más prácticas: ¿En qué archivo está ese cuaderno de notas? ¿Y cómo se mete en el contexto para que Claude "lo recuerde"? La última pregunta enlaza perfectamente con la gestión de contexto del artículo [19].

La ubicación, según la documentación oficial, es siempre un directorio de memoria específico para cada proyecto:

~/.claude/projects/<proyecto>/memory/
├── MEMORY.md          # Índice resumido, se carga en cada sesión
├── debugging.md       # Notas detalladas de depuración
├── api-conventions.md # Decisiones de diseño de la API
└── ...                # Otros archivos por tema creados por Claude

Vamos a desglosar esto en puntos clave:

MEMORY.md es la puerta de entrada y el índice. Es como el "índice general" de sus post-its, que Claude usa para saber "qué es lo que he apuntado en general". Los detalles los envía a archivos temáticos como debugging.md o api-conventions.md, para evitar que MEMORY.md crezca descontroladamente.

El nombre <proyecto> corresponde al repositorio git. Es decir: todos los worktrees y subdirectorios del mismo repositorio comparten la misma memoria automática. A diferencia del CLAUDE.md (que se une según la estructura del árbol de directorios).

Es local en tu máquina, no se sincroniza entre dispositivos. Lo que anote en este ordenador, no aparecerá en otro. Y ni se te ocurra meterlo en git: se queda en tu ~/.claude.

Y ahora viene el mecanismo más importante que debes entender: cómo se carga en el contexto. La regla oficial es estricta:

Las primeras 200 líneas o los primeros 25KB de MEMORY.md (lo que ocurra primero) se cargan al principio de cada conversación. El contenido que supere este límite no se cargará al iniciar la sesión.

Traducción a lenguaje humano en tres puntos:

1. En cada sesión nueva, lee automáticamente las primeras 200 líneas (o 25KB, el primero que llegue) de MEMORY.md. Así es como "se acuerda entre sesiones": lo que guardó la vez anterior, entra en el contexto en la nueva sesión.
2. Si supera las 200 líneas / 25KB, esa parte extra no se carga de inicio. Por eso Claude intenta mantener el MEMORY.md conciso de forma proactiva, enviando los detalles a archivos temáticos.
3. Los archivos temáticos (como debugging.md) tampoco se cargan de inicio, los lee usando la herramienta de archivos solo cuando cree que los necesita. Igual que la "carga bajo demanda" del CLAUDE.md en subdirectorios que vimos en el [18].

Pongamos las reglas de carga del CLAUDE.md y la memoria automática frente a frente:

	CLAUDE.md	Memoria automática MEMORY.md
Cantidad que carga	Todo, da igual lo largo que sea	Solo las primeras 200 líneas / 25KB
Qué pasa si te pasas	Carga todo (por eso te aconsejamos que lo hagas corto)	No se carga al inicio, se lee solo si hace falta
Quién lo mantiene corto	Lo borras tú a mano	Claude lo divide automáticamente

Sabiendo de este límite, entiendes por qué la memoria no "revienta" el contexto: la memoria automática tiene un tope de 200 líneas integrado de fábrica, mientras que en el CLAUDE.md el freno lo tienes que pisar tú.

💡 Resumen en una frase: La memoria automática se guarda en ~/.claude/projects/<proyecto>/memory/MEMORY.md, separada por repositorios de git en tu equipo local; en cada inicio de sesión se cargan solo las primeras 200 líneas o 25KB, y lo que sobra se envía a archivos temáticos que se leen bajo demanda, evitando así colapsar el contexto.

---

05 /memory: audita, edita y apaga, todo con un solo comando

Lo que más intranquilidad genera de la memoria automática es: "Si se lo anota él solo, ¿qué pasa si se equivoca o anota algo que ya está anticuado?" (Como el famoso error del puerto 8081). La respuesta oficial es un solo comando: /memory.

Analogía: Revisar los post-its. Las notas que se toma por su cuenta no son un bloque hermético al que no puedas acceder, puedes mirarlas cuando quieras e incluso tirarlas a la papelera. Usar /memory es el acto de "revisar los post-its".

Si tecleas /memory en una sesión, hará tres cosas:

1. Mostrarte una lista de todos los archivos de memoria que se han cargado en la sesión actual. Incluye CLAUDE.md, CLAUDE.local.md, archivos de reglas y la memoria automática. Si sospechas que "se ha acordado mal" de algo, este es el primer lugar para comprobar qué está leyendo.
2. Proporcionar un acceso a la carpeta de la memoria automática. Haces clic y te lleva al directorio memory/. Esos archivos son simples markdowns de texto plano, que puedes leer, modificar y borrar en cualquier momento. ¿Que la nota del puerto era errónea? La borras del documento directamente.
3. Ofrecer un botón para activar/desactivar la memoria automática. Si no quieres que siga apuntando cosas solo, puedes apagarlo desde aquí.

Aparte de usar /memory en el chat, hay otras dos formas "oficiales y fijas" para apagarla:

Desactivarla en settings.json (a nivel de proyecto, efecto permanente):

{
  "autoMemoryEnabled": false
}

O desactivarla de forma temporal usando variables de entorno (establece CLAUDE_CODE_DISABLE_AUTO_MEMORY=1).

Deberías adoptar esta costumbre: de vez en cuando, teclea /memory, entra en las notas y dales un repaso rápido. Muchas veces encontrarás cosas que deberías haber borrado hace tiempo: un puerto antiguo, un diseño de API descartado, o una "preferencia" incomprensible. Son un par de minutos, y te ahorrará que te guíe mal basándose en datos obsoletos. Es la mayor lección que se puede sacar de meter la pata con el puerto 8081.

💡 Resumen en una frase: Con /memory lo tienes todo a mano: ves qué archivos de memoria se han cargado, abres la carpeta de memoria automática para poder modificarla o borrarla como texto plano, y puedes apagar el sistema por completo; echarle un vistazo periódico y hacer limpieza de notas viejas es la forma más fácil de evitar que "recuerde cosas mal".

---

06 Qué guardar y qué NO guardar: No caigas en el error de "meterlo todo"

Ahora que conoces la mecánica, toca hablar del criterio más importante: qué merece la pena que recuerde y de qué deberías alejarlo totalmente. Esta es la experiencia que te ahorras gracias a los errores que otros ya han cometido.

La buena noticia es que la memoria automática suele ser bastante contenida por defecto (solo anota lo que "le servirá después"). Pero cuando eres tú el que le pide que apunte algo, tienes que hacer tú de filtro: si le dices "recuerda xxx", en general lo hará, el control lo tienes tú.

Aquí tienes una tabla comparativa, a la izquierda lo que lamentarás haber guardado, a la derecha lo que sí debes recordar:

❌ NO lo guardes (Un solo uso / Cambiante / Sensible)	✅ SÍ, guárdalo (Estable / Reutilizable / Propio del proyecto)
"Esta vez pon el puerto 8081" (Un solo uso)	"El build es con make build, no npm build"
"Cambia el nombre temporalmente a tmp" (Temporal)	"En este proyecto hace falta Redis local para los tests"
"Dejémoslo así de momento" (A punto de cambiar)	"El bug intermitente de la otra vez era por la zona horaria" (Notas de debug)
Contraseñas de BB.DD. / API keys / tokens (¡Peligroso!)	"Las fechas van en formato ISO 8601" (Preferencia de código)
"Ahora mismo estoy con el login" (Estado temporal)	"La lógica de auth va en src/auth/" (Arquitectura fija)

Para tomar la decisión, utiliza estos tres principios:

Primero: "¿Es algo que va a cambiar pronto?" Lo de usar una sola vez, lo inminente, el "apaño rápido"... nada de eso se guarda. Caducan más rápido que tu propia sesión, apuntarlo es sembrar minas para tu yo del futuro. Como el ejemplo del puerto 8081, que servía para ese instante pero dos días después no era más que desinformación.

Segundo: "¿Lo voy a volver a usar?" Si solo te vale para el problema actual ("Ahora mismo estoy con X"), no lo guardes; si es algo que usarás mañana o la semana que viene (comandos, arquitectura, los problemas con los que te tropiezas siempre), eso es lo que debe apuntar.

Tercero: "¿Es información confidencial?" Este es el límite rojo absoluto: ni contraseñas, ni tokens, ni API keys deben pisar nunca un archivo de memoria. La memoria automática son archivos de texto plano que se quedan en tu disco duro; guardar una clave ahí es dejarla al descubierto en el ordenador. Es lo mismo que la regla de seguridad universal: la información sensible no va en el código, no va en los commits, no va en los logs, y obviamente, no va en la memoria.

Antes de decirle que apunte algo, hazte estas tres preguntas mentales: ¿Va a cambiar? ¿Lo volveré a usar? ¿Es confidencial? Si pasa las tres pruebas, pídele que lo anote. Con este filtro, sus notas estarán mucho más limpias y no te dará respuestas erróneas por usar información caducada.

💡 Resumen en una frase: Pásalo todo por las tres preguntas: no anotes nada que vaya a cambiar, que solo uses una vez, o que sea confidencial; limítate a apuntar cosas "estables, reutilizables y propias del proyecto" (hechos y experiencias), y no intentes meter todo lo que pase.

---

07 ¿El viejo atajo # sigue sirviendo?

ℹ️ El símbolo # es un atajo antiguo, ya no se usa en las versiones nuevas. Varios tutoriales y vídeos viejos aún te dicen que "uses # al principio para añadir a la memoria rápido", pero olvídate de eso. La forma correcta ahora es: dile "recuerda xxx" para que vaya a la memoria automática, o "añádelo al CLAUDE.md" para que se guarde en las reglas de git.

Un error clásico de los principiantes: si le dices solamente "recuerda xxx", por defecto lo meterá en la memoria automática (en tu máquina local), y eso no significa que lo haya puesto en el CLAUDE.md (que entra en git y se comparte). Si quieres que la regla se aplique a todo el equipo, tienes que ser específico y decir "añádelo al CLAUDE.md". Es un pequeño matiz de palabras, pero el ámbito de quién lo puede ver cambia radicalmente.

💡 Resumen en una frase: Olvídate del atajo #; "recuerda xxx" lo pone en la memoria automática, "añádelo a CLAUDE.md" lo pone en git. Son dos cosas distintas, si quieres compartirlo, dilo claro.

---

08 Práctica: Dile que apunte algo, comprueba dónde va, y que se acuerde la próxima vez

Leer sobre esto no es lo mismo que hacerlo. Te guiaré por todo el proceso: pídele que apunte algo → asegúrate de que cae en la memoria automática → comprueba que la próxima vez que entres se acuerda de ello por sí solo. Un ejemplo mínimo que no requiere ninguna preparación complicada.

ℹ️ Requisito: claude --version ≥ v2.1.59 y la memoria automática activada (viene así por defecto).

Paso 1: Crea un proyecto de prueba y arranca Claude (Mac / Linux)

mkdir memory-demo
cd memory-demo
claude

Qué debería pasar: Estarás en la interfaz de chat de Claude Code con la caja de entrada lista.

Paso 2: Pídele que se apunte una cosa

En la caja de texto, dile (usaremos un ejemplo de "comando de construcción", que es algo típico y muy útil):

Recuerda: el comando de build de este proyecto es make build, no npm build

Qué debería pasar: Claude responderá que lo ha anotado, y en la pantalla aparecerá brevemente un mensaje que dice "Writing memory" (escribiendo en la memoria). Ver eso significa que lo está anotando en su libreta.

Paso 3: Usa /memory para comprobar a qué archivo ha ido a parar

Inmediatamente después, teclea:

/memory

Qué debería pasar: Se abrirá la pantalla de gestión de memoria, con los archivos que están cargados actualmente. Verás la sección de memoria automática y, si haces clic para entrar, llegarás a MEMORY.md. Ahí dentro encontrarás el apunte de make build que le pediste. Si está en ese archivo = ya no es solo "palabras en el chat", sino una "nota escrita en el disco".

Si prefieres mirarlo directamente desde la terminal, abre otra consola diferente y ejecuta:

cat ~/.claude/projects/*memory-demo*/memory/MEMORY.md

Qué debería pasar: La salida te mostrará la nota del comando de build (el nombre <proyecto> de la ruta de archivo es el tuyo; usa el comodín * para no tener que buscarlo exacto). Es puro texto markdown, muy fácil de leer.

Paso 4: Comprueba que en la siguiente sesión funciona automáticamente

Esta es la parte importante: el sentido de la memoria es que cruce sesiones. Sal de la actual:

/exit

Vuelve a entrar, y pregúntale por algo relacionado con lo que anotaste:

claude

Y ponle:

¿Cómo se hacía el build de este proyecto?

Qué debería pasar: Te responderá de inmediato que se hace con make build (y no inventándose un npm build). Y es muy probable que te aparezca un mensaje de "Recalled memory" (recuperado de la memoria), confirmando que ha leído lo que anotaste la última vez. Ha acertado a la primera en una sesión nueva = la memoria cruzada de sesión funciona, ¡enhorabuena!

Paso 5 (Opcional): Bórralo y comprueba que se le olvida

Entra en /memory, abre la carpeta de memoria automática y borra la línea del make build y guarda el archivo. Si le vuelves a preguntar "¿Cómo se construía?", ya no te dirá con tanta seguridad make build, porque lo has borrado de sus notas. Esto te demuestra el poder que tienes de "abrir y arrancar páginas" con /memory.

Haciendo estos cinco pasos habrás recorrido todo el camino con tus propias manos: "Anotar → Guardar a disco → Recuperar en nueva sesión automáticamente → Auditar/Editar en cualquier momento". El resto de trucos sobre la memoria se basan todos en esta misma mecánica.

💡 Resumen en una frase: Pídele que "recuerde xxx" → mira si pone "Writing memory" → usa /memory o cat para confirmar que está en MEMORY.md → sal, vuelve a entrar, mira si pone "Recalled memory" y responde bien → borra o edita con /memory cuando lo necesites. Hacerlo tú mismo te servirá más que aprenderte diez conceptos teóricos.

---

09 Resumen

En este artículo hemos destripado el "sistema de memoria" de Claude Code: no es solo uno, son dos paralelos; y no se trata de que lo apunte todo, sino de que apunte solo lo preciso.

Repasemos los puntos clave para unirte los conceptos:

Lo que debes saber	Conclusión
¿Cuántos sistemas de memoria hay?	Dos: CLAUDE.md con tus reglas escritas a mano + La memoria automática con sus notas
¿En qué se diferencian?	Quién los escribe, si guardan reglas o aprendizajes, si se carga completo o hay límite: una tabla para verlo todo claro.
¿Dónde se guarda la memoria automática?	En ~/.claude/projects/<proyecto>/memory/MEMORY.md, separada por repositorio git, solo en local
¿Cómo entra en el contexto?	Al iniciar lee solo las primeras 200 líneas / 25KB de MEMORY.md, y si necesita más, lee los otros archivos bajo demanda
¿Cómo revisar y modificar?	Con /memory: ves los archivos que usa, abres la carpeta para leer/editar/borrar, y lo puedes apagar
¿Qué guardar y qué no?	El filtro de las tres pruebas: No guardes lo que vaya a cambiar, lo que sea de un uso, ni lo confidencial
¿Sirve todavía #?	Está anticuado; di "recuerda xxx" para la memoria automática, o "añádelo a CLAUDE.md" para git

Ahora serás capaz de: Entender las diferencias entre CLAUDE.md y la memoria automática y dónde se guarda cada cosa; hacer que Claude apunte algo y verificar en qué archivo ha terminado; usar /memory para borrar notas desfasadas o equivocadas; y tener un criterio claro sobre qué vale la pena apuntar y qué no. Dicho claro: ahora puedes guiar a Claude para que "se acuerde de lo importante y se olvide de lo que no sirve", sin miedo a que acumule datos basura.

La memoria es, en esencia, Claude "absorbiendo información pasivamente": tú corriges, él aprende. Pero lo que puede hacer por ti va mucho más allá de simplemente apuntar cosas.

---

En el próximo artículo, 26 "Agent Skills", pasaremos de "absorber pasivamente" a "ofrecer herramientas activamente": agrupar una tarea repetitiva que le mandes muchas veces en una "habilidad especial" para que él mismo pueda sacarla a relucir cuando toque. Si la memoria hace que te "entienda mejor", las Skills hacen que "sepa hacer más cosas". Piensa en ello: ¿en qué se diferencia y en qué momento debes optar por "que se aprenda una regla" y cuándo por "que adquiera una nueva habilidad"? Lo vemos.

---

Lecturas recomendadas

• Configuración de API: Suscripción o API key, cómo elegir y cómo cambiar
• Práctica para empezar: Aceptando un encargo real, de principio a fin
• Guía de CLAUDE.md: Poniéndole reglas al proyecto