La entrada anterior defendió que CLAUDE.md solo guarda invariantes. Entonces, ¿qué va en memory? Abrí los 5 archivos de memory que corren hoy en este proyecto y los audité uno por uno: qué se queda, qué debería borrarse y dónde cae realmente la línea entre CLAUDE.md y memory.
La entrada anterior defendió que CLAUDE.md solo debería contener lo que Claude no puede ver leyendo el código. Un lector preguntó enseguida: ¿y qué pasa con memory? Memory también es contexto — ¿cuál es la diferencia real?
Mucha gente termina tratando memory como una "extensión de respaldo" de CLAUDE.md — mete ahí cualquier cosa que se le ocurra. Con el tiempo, memory se hincha, Claude la lee en cada sesión y las decisiones se toman con información obsoleta.
Este artículo salta las definiciones abstractas. Abrí los 5 archivos de memory que corren ahora mismo en este proyecto y los audité uno por uno — cuáles se quedan, cuáles se van y cuáles nunca debieron escribirse. Por el camino, la pregunta CLAUDE.md vs memory se responde sola.
La pregunta útil no es "¿dónde va esto?" — es "¿cuánto vive esta información y quién la actualiza?"
feedback_commits — esperar a que yo diga "commit" antes de hacer commit
feedback_article_authenticity — los artículos prácticos no se inventan
project_i18n_strategy — la decisión de "lanzar todos los idiomas a la vez"
project_howdev_plan — plan sin terminar para how2claude.dev
project_article_workflow — el pipeline de publicación de artículos
Agrupados por tipo.
El cuerpo es corto: "don't auto-commit, wait for user to confirm."
Es el tipo de memory con mayor ROI. Una corrección → permanente en todas las sesiones futuras.
¿Por qué no en CLAUDE.md? No es una regla del proyecto — es mi hábito personal de trabajo. Si otro colaborador se uniera al proyecto, no necesariamente tendría que seguir la misma regla. CLAUDE.md es a nivel de equipo. Memory es "entre Claude y yo."
¿Por qué no repetirlo al inicio de cada conversación? Porque memory persiste entre sesiones. Cuando Claude me ayude la semana que viene, seguirá recordándolo.
El disparador es claro: corregí algo una vez y quiero que la corrección dure para siempre.
El cuerpo de este memory es inusualmente específico:
El 2026-04-16, mientras escribía el cierre de la serie multi-agent, inventé una historia sobre "tres Agents construyendo una feature de webhook"... toda inventada. El usuario preguntó "¿es real o inventado?" — que es una vara distinta a la de los dos artículos anteriores (metodológicos)...
El punto: el campo Why no es un principio abstracto — es un evento específico + fecha + qué pasó.
¿Por qué escribirlo así? Dentro de seis meses, "los artículos prácticos necesitan material real" como regla abstracta me dejará desconcertado — ¿cuándo se fijó esto, por qué se fijó? Pero "4-16, inventé una historia de agent y me pillaron" dispara un recuerdo instantáneo y me deja juzgar en el momento si la regla sigue aplicando.
Es la entrada más "pesada" de mis 5. No es solo una regla — es un expediente de incidente que tanto Claude como yo podemos consultar.
El contenido: por qué este proyecto lanzó agresivamente todos los idiomas a la vez — el costo de traducción vía Claude es ~$0, y que la documentación oficial solo esté en inglés es la ventana de oportunidad central.
Esto no se ve en el código. El código solo muestra 19 archivos de locale. Por qué 19, por qué todos a la vez, por qué japonés y coreano son prioritarios — todo eso vive en mi cabeza.
Memory destila esa "decisión mental" en algo duradero, para que cuando Claude sugiera una función más adelante pueda preguntarse: ¿esto choca con la estrategia i18n?
No es una regla operativa (no va en CLAUDE.md). Es trasfondo estratégico (va en memory).
El más temporal del grupo: un plan de implementación de 9 archivos para el sitio de desarrolladores how2claude.dev, terminando con "continuará en la próxima sesión."
Es el tipo de memory más peligroso — fácilmente se convierte en memory zombie. Terminás el trabajo y te olvidás de borrarlo; la próxima vez, Claude lo trata como vigente y aconseja según un plan obsoleto ("aún no hiciste el step 3").
Estas memories necesitan un mecanismo de salida explícito: en el momento en que how2claude.dev se lance, tengo que borrar esta entrada manualmente.
Esta tiene la mayor densidad de información. Al principio pensé que era la más útil — hasta que la leí con atención:
/write-article y /publish-article → mirar .claude/commands/, listodocs/drafts/ lo hace obvio.claude/publish-config.jsonClaude puede deducir todo eso leyendo el código.
Lo único que memory realmente aporta es el último bloque: "Accounts (production): zh → @how2claude, en → @howtoclaude" — y eso ya está obsoleto. La última sesión mostró que producción en realidad es zh=@howtoclaude. El memory capturó una foto de hace unos días; ya está desalineado.
Conclusión: el 90% de este memory debería irse. Lo que vale la pena conservar ("usar kamal para consultar cuentas en vivo") encaja mejor en CLAUDE.md — o mejor aún, en ningún lado, porque las cuentas hardcodeadas en memory se desalinearán otra vez.
1. El verdadero trabajo de memory es abrir habitaciones en las que Claude no puede entrar.
2. Si Claude puede leerlo del código, no lo pongas en memory.
Mismo principio que el artículo anterior de CLAUDE.md. Rutas de archivos, URLs de API, estructura de directorios — todo lo puede responder el código. Meterlo en memory porque no querés hacer un grep es apostar a que nada va a cambiar nunca.
3. Memory se degrada.
project_article_workflow es la prueba — escrito hace días y la información de cuentas ya está mal. Cuanto más vieja la memory, menos fiable. Auditar regularmente > agregar sin parar.
4. El campo Why es lo que te salva.
Comparando mis dos feedback:
feedback_article_authenticity: "4-16, inventé una historia en el artículo multi-agent" → seis meses después puedo juzgar al instante si sigue aplicando.feedback_commits: "user wants to review" — seis meses después no estoy seguro de qué corrección específica lo originó.El segundo es mucho más débil. Los principios abstractos no sobreviven — nadie recuerda por qué se impusieron.
Cuando aparece nueva información, hacé tres preguntas:
La tercera pregunta es la trampa. La mayor parte del material "que no cambia" que querés anotar en realidad es deducible del código — simplemente no querés que Claude haga grep otra vez.
Hay unas cuantas cosas:
project_article_workflow es deducible del código. Esta es la que más cirugía necesita.project_howdev_plan es un traspaso temporal — en teoría debería tener un mecanismo de salida.project_i18n_strategy es una decisión estratégica — vale la pena revisarla en unos meses.feedback_commits es débil; agregarle un evento específico lo haría más robusto.Observación lateral: mi distribución de tipos es feedback×2 + project×3, con cero tipos user o reference. Eso significa que aún no le dije a Claude "quién soy" ni "de qué sistemas externos leo estado". Probablemente lo próximo a escribir.
La trampa más grande de memory no es "lo que debí escribir y no escribí." Es "lo que escribí y ya está obsoleto." Con 5 entradas, una sola desalineación alcanza — Claude usa tranquilamente información vieja para decidir, y no te va a señalar el desajuste.
En mis 5, ya veo un par de cosas para mover. ¿Y las tuyas?