El segundo cerebro

Memoria en archivos: no volver a perder nada

Un LLM es amnésico entre sesiones (lección 1.1). La solución industrial: una memoria en archivos persistente que Claude relee y actualiza. El sistema de Pierre es el caso de referencia.

Principio: una carpeta memory/ donde cada hecho duradero es un archivo markdown con frontmatter (name, description, type: user / feedback / project / reference). Un archivo MEMORY.md actúa como índice: una línea por memoria, cargado en cada sesión.

Tres categorías que estructuran todo:

• feedback: cómo debe trabajar Claude (correcciones, preferencias). Con el porqué.
• project: el estado de un trabajo, las decisiones, las restricciones no deducibles del código.
• reference: punteros a recursos externos.

Una disciplina clave, codificada por Pierre: actualizar la memoria después de cada lote entregado, no solo al final de la sesión. Así no se pierde ningún detalle ni contexto. Y solo se almacena lo que no está ya en el código (git y el CLAUDE.md ya lo indican): se guarda lo no evidente.

Obsidian: el segundo cerebro navegable

Pierre montó su memoria de archivos como un vault de Obsidian: la misma fuente única, pero navegable visualmente. Las técnicas que marcan la diferencia:

• Wikilinks [[nombre-de-nota]]: cada nota apunta a notas relacionadas. Se teje una red, no una pila de archivos. Un enlace a una nota aún no escrita es válido: señala un vacío por rellenar.
• MOC (Map of Content): notas-concentradoras (_MOC_feedbacks, _MOC_projects, _absolute_rules) que agrupan enlaces por tema. Un punto de entrada temático.
• Notas atómicas: un hecho por nota, densamente enlazadas. Más fácil de encontrar y recombinar.
• Vista de grafo: el mapa visual del vault, para ver clusters y vacíos.

El protocolo "sync memory" de Pierre formaliza el mantenimiento: crear o actualizar la nota, tejer sus wikilinks hacia las notas relacionadas, añadirla al MOC correcto y al índice. No solo reconciliar el índice: tejer la red. Un segundo cerebro vale por sus enlaces, no por sus archivos aislados.

Graphify: consultar una base de código en lugar de releerla

Graphify (uno de los skills de Pierre) convierte cualquier carpeta (código, documentos, artículos, video) en un grafo de conocimiento persistente y consultable. Pipeline: detectar los archivos -> extraer el AST (código) y el significado (documentos) en paralelo -> detectar comunidades (clustering) -> exportar a HTML/Obsidian/Neo4j.

La ganancia es enorme y contraintuitiva: en lugar de releer 30 archivos para responder "¿quién llama a esta función?", se consulta el grafo (/graphify query, /graphify path, /graphify explain). Según las mediciones de Pierre, hasta ~71x menos tokens que una relectura. Es la optimización de contexto (módulo 7) aplicada al conocimiento del código.

Su regla es conectar Graphify a cada proyecto, nuevo o existente, en modo AST local (gratuito), mediante un helper graphify-init.ps1, e inyectar el grafo en el vault de Obsidian (_graphify\<proyecto>). Los hooks de git actualizan los grafos en cada commit. Resultado: dispone de 8 repos y un brain-graph de cientos de nodos, todos consultables sin releer nada.

Lección general: para grandes bases de conocimiento, indexar una vez, consultar con frecuencia supera a releer en cada pregunta. Aplica tanto al código como a tu memoria.

Dream: consolidación nocturna automática

El skill dream de Pierre aplica el concepto de consolidación de memoria (inspirado en el sueño) a su vault. Una tarea programada lo ejecuta cada noche. En cuatro fases:

1. Orientarse: tomar referencias en la memoria existente.
2. Reunir la señal: releer las conversaciones recientes y la memoria.
3. Consolidar: extraer hechos duraderos, fusionar duplicados, archivar (nunca eliminar) las contradicciones, tejer los enlaces.
4. Verificar: mantener MEMORY.md como índice limpio.

Todo respeta sus reglas absolutas: nunca eliminar (archivar en una carpeta con fecha), sin emoji, sin guion largo, el índice permanece como índice. Una copia de seguridad precede cada pasada, y se ejecuta en modo headless.

Este es el punto culminante del segundo cerebro: un sistema que se limpia y se fortalece solo mientras Pierre duerme. La práctica diaria (memoria actualizada después de cada lote) proporciona la materia prima; Dream la digiere, deduplica y enlaza. Sin esa digestión, una memoria crece hasta volverse ilegible. Con ella, se mantiene viva.

Aprendizaje continuo: aprender de la propia práctica

El último nivel del sistema: el skill continuous-learning. Analiza el historial git de los repositorios durante 90 días, detecta los patrones recurrentes (comandos repetidos, los mismos correctivos, despliegues escritos, con un umbral de ocurrencia) y propone convertirlos en nuevos skills o reglas para agregar al CLAUDE.md.

La idea es profunda: tu práctica diaria ya contiene las automatizaciones que necesitas, en forma de repeticiones. En lugar de intuirlas, las extraes de los datos (el historial git) y las codificas.

El ciclo completo del segundo cerebro de Pierre:

• Él trabaja (sesiones de Claude Code en sus proyectos).
• Él consolida después de cada lote (memoria); Dream digiere por la noche.
• Graphify indexa el código en grafos consultables.
• Continuous-learning extrae los patrones repetidos en nuevos skills y reglas.

Resultado: un sistema que mejora en cada sesión sin esfuerzo dedicado. Este es el nivel experto del uso de Claude: no solo usar la herramienta, sino construir a su alrededor una máquina que aprende.

Notas atómicas

Una nota atómica contiene exactamente una idea, un hecho o una decisión. La palabra "atómica" significa indivisible: no se puede dividir la nota más sin perder significado. En un segundo cerebro (un sistema de conocimiento personal que almacena y conecta información fuera de tu mente), las notas atómicas son la unidad útil más pequeña.

Las notas extensas que cubren varios temas crean un problema de archivo: nunca se sabe qué categoría las contiene, y recuperar un solo hecho obliga a leer todo lo demás. Las notas pequeñas tienen un único lugar y una única función. Además se recombinan libremente porque cada una se sostiene por sí misma.

El poder de las notas atómicas proviene de la vinculación. Cuando cada archivo contiene una sola idea, las conexiones entre archivos se vuelven significativas. Una nota sobre "límites de la ventana de contexto" puede enlazar a "estrategia de fragmentación", "conteo de tokens" y "caché de prompts" sin duplicar contenido. Claude Code y herramientas como Graphify (un inyector de grafos de código que usa Pierre) pueden recorrer esos enlaces y mostrar notas relevantes sin releer miles de líneas.

• Una idea por archivo: si usas "y" en el título, divide la nota.
• Título descriptivo: el título debe hacer que el contenido sea predecible desde un resultado de búsqueda.
• Sin notas huérfanas: cada nota nueva recibe al menos un enlace a una nota existente.
• Preferir sustantivos: nombra el concepto, no el proyecto ("presupuesto de tokens", no "el problema de tokens del lunes").

Wikilinks y mapas de contenido

Un wikilink es una referencia entre corchetes dobles como [[note-title]] que crea una conexión clicable entre dos notas. En Obsidian (la aplicación de toma de notas que se usa como segundo cerebro), cada wikilink que escribes se convierte en una arista visible en la vista de grafo. Cuando Claude lee tu vault, esos enlaces son también metadatos legibles: le indican qué conceptos están relacionados sin que tengas que repetir la explicación.

Un mapa de contenido (MOC, por sus siglas en inglés) es una nota cuya única función es listar y enlazar otras notas sobre un tema. Piensa en ella como un índice elaborado a mano. A diferencia de una carpeta, una MOC puede aparecer en múltiples contextos y puede enlazar entre temas distintos. Convenciones de nomenclatura comunes: _MOC_projects, _MOC_skills, _MOC_reference.

Juntos, los wikilinks y las MOC ofrecen a tu vault dos modos de navegación:

• Retroenlaces: cada nota muestra qué otras notas apuntan hacia ella, lo que permite rastrear dónde se usa una idea.
• Recorrido por hubs: abres una MOC y navegas a cualquier subtema en segundos, sin necesidad de buscar.

Cuando le pides a Claude Code que actualice la memoria, indicarle que agregue un [[wikilink]] a la MOC relevante y a MEMORY.md significa que la nueva nota es inmediatamente accesible desde dos puntos de entrada. El grafo se mantiene coherente sin mantenimiento manual.

Tipos de memoria

Claude Code organiza el conocimiento persistente en cuatro tipos de memoria, cada uno almacenado en un archivo distinto y cargado en un momento diferente. Entender cuál usar evita la acumulación innecesaria y garantiza que el contexto correcto llegue en el momento adecuado.

• Memoria de usuario: preferencias y reglas globales que se aplican a todos los proyectos. Almacenada en ~/.claude/CLAUDE.md. Ejemplos: tu nombre, el idioma preferido, la regla sin emoji, el estilo de commit.
• Memoria de proyecto: información específica de una base de código. Almacenada en .claude/CLAUDE.md en la raíz del repositorio. Ejemplos: la pila tecnológica, las convenciones de carpetas, los nombres de variables de entorno, la estrategia de ramas.
• Notas de retroalimentación: lecciones aprendidas de errores o correcciones. Se nombran feedback_*.md en tu vault. Ejemplos: "nunca eliminar, siempre archivar", "sin jq en Windows, usar node". Se referencian desde MEMORY.md para que Claude las cargue bajo demanda.
• Notas de referencia: documentos factuales estables que Claude puede necesitar consultar. Se nombran reference_*.md. Ejemplos: flujo de trabajo de la API, límites de cuota, versiones de herramientas. No son reglas sino tablas de consulta.

La separación es importante porque la memoria de usuario se carga incondicionalmente en cada sesión, por lo que debe ser breve y universal. La memoria de proyecto solo se carga cuando Claude inicia dentro de ese repositorio. Las notas de retroalimentación y de referencia se cargan bajo demanda mediante enlaces en MEMORY.md, manteniendo liviana la ventana de contexto activa (la memoria de trabajo que Claude conserva durante una conversación).

Un error común es escribir reglas específicas de un proyecto en la memoria de usuario, o volcar todos los datos en un único archivo enorme. Mantena cada nota atómica (un tema por archivo), enlázala desde el índice correcto, y Claude recuperará exactamente lo que necesita sin desperdiciar tokens (la unidad que mide cuánto texto puede procesar Claude a la vez).

Recordar en lugar de releer

Cada vez que le pides a Claude que relea un archivo fuente solo para responder una pregunta, gastas tokens (las unidades de texto que procesa el modelo) en contenido que tus notas ya resumen. En el nivel Experto, el hábito que debes cultivar es consultar tus notas primero y abrir el archivo sin procesar solo cuando la nota sea insuficiente.

Un segundo cerebro bien mantenido (tu vault de Obsidian o cualquier sistema de notas enlazadas) almacena el significado destilado de cada archivo: decisiones clave, puntos de entrada, errores comunes y enlaces cruzados. Pedirle a Claude que consulte ese grafo cuesta una fracción de lo que costaría pedirle que lea docenas de archivos fuente desde cero. Con una herramienta como Graphify (un constructor de grafos de código que mapea tu repositorio en nodos y aristas), una sola consulta al grafo puede reemplazar la lectura de todo un árbol de módulos.

El flujo de trabajo tiene tres niveles:

• Nivel 1 - recordar: pide a Claude que consulte tus notas o el grafo para obtener la respuesta.
• Nivel 2 - lectura dirigida: si la nota apunta a un archivo y un rango de líneas específico, lee solo esa porción.
• Nivel 3 - lectura completa: usa esto solo cuando la nota esté desactualizada o la pregunta sea estructural y genuinamente nueva.

Este enfoque por niveles es la forma en que un ingeniero senior trabaja con una base de código grande: el modelo mental primero, el archivo fuente solo como último recurso. Tus notas son tu modelo mental en disco.

Inyectar conversaciones en el cerebro

Cada sesión de Claude Code que has ejecutado es un registro valioso: prompts, cadenas de razonamiento, ediciones de código y resultados. Por defecto, esas sesiones se guardan en un directorio de registros local y nunca se vuelven a leer. Inyectar conversaciones en el grafo de conocimiento significa exportar esos registros, analizarlos e inyectarlos en tu vault de Obsidian (tu segundo cerebro) para que Claude pueda consultarlos en sesiones futuras sin releer el texto sin procesar.

El paso de exportación utiliza claude-extract, una pequeña utilidad de Node que lee los archivos de sesión de Claude Code (almacenados en ~/.claude/projects/ como archivos JSONL, donde JSONL significa un objeto JSON por línea). En Windows, define PYTHONUTF8=1 antes de ejecutar cualquier variante basada en Python para evitar errores de codificación con caracteres acentuados.

Una vez exportadas, las transcripciones se depositan en una carpeta (convencionalmente _conversations/ dentro de tu vault). Graphify las ingiere a continuación: construye un grafo de tipo AST (AST significa Abstract Syntax Tree, un mapa estructurado de relaciones) que enlaza los nodos de sesión con los nodos de proyecto, los nodos de skills y las notas de memoria. El grafo resultante puede alcanzar miles de nodos y permite a Claude responder preguntas como "¿qué decidimos sobre la geometría de las puertas en Plan2Tour?" recorriendo las aristas del grafo en lugar de releer cientos de archivos.

• Ubicación de los archivos de sesión: ~/.claude/projects/<ruta-codificada>/, un JSONL por sesión.
• Comando de exportación: claude-extract (ejecutar con PYTHONUTF8=1 en Windows).
• Destino: carpeta _conversations/ dentro de tu vault de Obsidian.
• Actualización del grafo: ejecuta graphify update <repo> o activa la tarea programada que se ejecuta cada noche.
• Beneficio de las consultas: recorrer el grafo consume muchos menos tokens que leer transcripciones sin procesar, hasta 71 veces menos en vaults grandes.

Actualización nocturna

Un segundo cerebro (su vault de Obsidian vinculado a Claude Code) solo es útil si sus datos están al día. El código cambia a diario, las notas nuevas se acumulan y el grafo de conocimiento (el mapa de conexiones entre archivos, funciones y notas) pierde sincronización durante la noche. La consolidación programada consiste en ejecutar tareas automatizadas a una hora fija cada noche para que todo quede alineado antes de que comience la siguiente sesión de trabajo.

Dos tareas complementarias se encargan de esto: un refresco del grafo (reanalizando todos los repositorios con Graphify para actualizar nodos y aristas AST) y un pase de sueño (un agente de consolidación que lee las notas recientes, promueve los conocimientos importantes a la memoria permanente y teje nuevos wikilinks). Ejecutarlos en secuencia, primero el grafo y luego el sueño, garantiza que el agente de sueño siempre razone sobre el grafo más actualizado.

En Windows, el Programador de tareas gestiona ambas. Cada tarea llama a un script PowerShell que cambia al directorio correcto, invoca claude en modo no interactivo con un prompt preparado y registra el resultado. Las opciones clave son:

• --print : ejecuta un solo turno de forma no interactiva, imprime la respuesta y termina.
• --model claude-opus-4-8 : usa Opus para el pase de sueño (razonamiento intensivo); use claude-sonnet-4-6 para el resumen de metadatos del grafo, que es más económico.
• --output-format text : escribe una salida en texto plano que el script puede agregar a un archivo de registro.
• --max-tokens 2048 : limita la salida para evitar costos elevados en una tarea desatendida.

El resultado: cada mañana el índice de su vault está actualizado, sus notas de memoria contienen los conocimientos de la noche anterior y Claude Code carga un grafo que refleja lo que realmente existe en lugar de una instantánea desactualizada.