Segundo cerebro con Claude Code: configuración y flujo de revisión

Un segundo cerebro (second brain) con Claude Code es tu carpeta de notas con Claude Code funcionando dentro. Claude Code es el agente de programación de Anthropic, pero no tiene nada específico del código: lee archivos, escribe archivos, busca en carpetas y ejecuta comandos. Apúntalo a una bóveda de Obsidian y podrá ordenar tu inbox, convertir notas de reuniones en actualizaciones de proyecto, responder preguntas a partir de todo lo que has escrito y mantener al día los enlaces entre notas.

La diferencia con una app de chat es que las notas son la memoria. No pegas contexto en cada conversación. Claude lee del disco lo que necesita, y todo lo que escribe se queda en archivos markdown planos que son tuyos. La LLM wiki de Andrej Karpathy es la misma idea llevada más lejos: el agente mantiene una wiki entera a partir de tus fuentes.

Hay una pega. Un agente que puede mejorar cualquier nota también puede cambiar sin avisar una nota en la que confías. Por eso esta guía explica el montaje y, en la misma medida, cómo ver y aprobar lo que cambia Claude: con git, que funciona hoy, y con Knowtarium.

Knowtarium es una base de conocimiento cifrada de extremo a extremo para notas que escriben juntos personas y agentes. Claude Code se conecta a ella por MCP, cada cambio que hace Claude va firmado, muestra quién lo hizo y se puede deshacer, y cada nota muestra quién la escribió (y, en las carpetas con revisión activada, quién la revisó). Empezar es gratis. A lo largo de la guía, unas notas breves cuentan cómo resuelve Knowtarium cada parte.

Necesitas tener Claude Code instalado (consulta la documentación de Anthropic) y una carpeta de notas en markdown. Obsidian es opcional: Claude solo necesita la carpeta.

1. Haz primero una instantánea

Antes de que Claude toque nada, pon la bóveda bajo git y haz commit. Es tu botón de deshacer para todo lo que viene después, y lleva un minuto. Añade un .gitignore para que los archivos de diseño de Obsidian no ensucien cada diff:

# Obsidian los reescribe constantemente; déjalos fuera de tus diffs
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/
CLAUDE.local.md

2. Inicia Claude Code en la bóveda

$ cd ~/Notes                  # tu bóveda$ git init && git add -A$ git commit -m "before Claude"$ claude
> /init

/init examina la carpeta y redacta un CLAUDE.md. Está pensado para código, así que toma el borrador como punto de partida y reescríbelo con las reglas de más abajo. Ejecuta /context para confirmar que el archivo se ha cargado.

3. Decide cuánto puede hacer Claude sin preguntar

Claude Code tiene modos de permisos. En el modo Manual pregunta antes de cada edición. El modo Plan hace que proponga un plan sin editar nada, lo que encaja con una primera sesión en una bóveda que te importa. Cambias de uno a otro con Shift+Tab. La página de los modos de permisos indica en qué modo empieza una sesión, lo que depende de tu versión y de tu cuenta.

En Knowtarium

Los modos de permisos deciden qué puede hacer Claude durante una sesión. Knowtarium cubre el resto: conectas Claude a un espacio de trabajo, solo a algunas carpetas si quieres, y con acceso de solo lectura o de lectura y escritura. Cada cambio que hace va firmado y se puede deshacer con un clic. Los agentes solo pueden borrar si les diste ese permiso (una nota borrada vuelve con Undo mientras tu periodo de historial la conserve), y no pueden marcar una nota como revisada por ti. En las carpetas que quieras aprobar antes, activa la revisión (“Ask me first”), y los cambios de Claude en ellas te esperarán.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

CLAUDE.md es un archivo markdown que Claude Code lee al principio de cada sesión. Para una bóveda, debería responder a tres preguntas: cómo está organizada la bóveda, cómo debe escribir Claude y qué tiene que contarte al terminar. La documentación sobre memoria de Anthropic da las reglas que importan:

• Que no pase de unas 200 líneas. Los archivos más largos ocupan más contexto y se siguen con menos fiabilidad.
• Escribe instrucciones que puedas comprobar (“journal/ es de solo lectura”, no “ten cuidado con mis notas”).
• Incluye otros archivos con importaciones @path, como una nota con tus prioridades actuales.
• Un CLAUDE.md en una subcarpeta se carga cuando Claude lee archivos de ahí, así que un proyecto grande puede llevar sus propias reglas.
• Pon las notas personales que no quieras en git en CLAUDE.local.md.

# Esta bóveda
 
Notas personales, gestionadas en Obsidian. Markdown plano, wikilinks.
 
## Estructura
- inbox/: capturas sin procesar. Procésalas y luego sácalas de ahí.
- projects/: una carpeta por proyecto activo, con un README.md.
- areas/: temas continuos (salud, dinero, trabajo).
- journal/: mis notas diarias. Léelas, nunca las edites.
- archive/: proyectos terminados. No los toques.
 
## Cómo escribir
- Conserva mis palabras. Añade, no reescribas, salvo que te lo pida.
- Las notas nuevas llevan frontmatter: type, created, source.
- Cuando afirmes un dato, enlaza la nota o la URL de donde sale.
- Enlaza a las personas como [[Nombre Apellido]] y los proyectos como [[Nombre del proyecto]].
 
## Después de cada tarea
- Enumera los archivos que has creado, cambiado o movido.
- Añade una línea a log.md: fecha, qué has hecho, qué archivos.
 
Prioridades actuales: @context/now.md

“Conserva mis palabras” y “enumera los archivos que has cambiado” son las dos líneas que más gente desearía haber escrito el primer día. La primera evita que Claude borre tu voz de tus notas a base de pulirlas. La segunda hace posible la revisión.

Convierte las reglas importantes en reglas obligatorias

La documentación deja claro que CLAUDE.md es contexto, no una configuración que se haga cumplir. Claude intenta seguirlo, sin garantías. Para las carpetas que nunca deben cambiar, añade una regla de denegación a .claude/settings.json en la bóveda. Las reglas Edit cubren las herramientas de archivos de Claude y los comandos de shell habituales, aunque no un script que abra archivos por su cuenta, así que mantén git como red de seguridad.

{
  "permissions": {
    "deny": ["Edit(/journal/**)", "Edit(/archive/**)"]
  }
}

Claude Code tiene dos tipos de memoria, y conviene saber dónde vive cada una.

Cuando le dices a Claude “recuerda que reviso las facturas los viernes”, va a la auto memory. Cuando le dices “añade esto a CLAUDE.md”, va al archivo. /memory muestra las dos y las abre.

Para un segundo cerebro, guarda el contexto que te importa dentro de la bóveda, donde puedes leerlo, git lo sigue y todos los agentes lo ven. Un pequeño context/now.md con las prioridades de la semana, importado desde CLAUDE.md, hace más que un archivo de memoria largo. Actualízalo tú los lunes, o pide a Claude que redacte la actualización y revísala como cualquier otro cambio.

Casi todo el valor sale de un puñado de tareas que se repiten:

• Ordenar el inbox. Claude propone dónde va cada captura, tú lo apruebas, y él mueve las notas y las enlaza.
• De notas de reunión a actualizaciones de proyecto. Pega o suelta una transcripción; Claude escribe un resumen, actualiza el README del proyecto y enumera las acciones pendientes.
• Pregunta a tus notas. “¿Qué decidí sobre la página de precios y por qué?” Pídele que responda con enlaces a las notas que ha usado.
• Revisión semanal. Que lea el diario y las notas de proyecto de la semana y redacte una nota de repaso, sin editar los originales.
• Mantenimiento de enlaces. Que encuentre notas huérfanas, enlaces rotos y notas que deberían enlazarse entre sí, y proponga las correcciones en una lista.

Convierte en una skill cada tarea que repitas. Una skill es un archivo SKILL.md en .claude/skills/<name>/; lo ejecutas escribiendo /<name>, y Claude también puede usarla por su cuenta cuando tu petición encaja con su descripción. A diferencia de CLAUDE.md, una skill solo se carga cuando se usa, así que los procedimientos detallados no cuestan casi nada el resto del tiempo.

---
description: Procesa el inbox. Úsala cuando diga 'procesa el inbox' o 'triage'.
---
 
Para cada nota de inbox/:
1. Decide dónde va: un proyecto, un área o la papelera.
2. Enséñame el plan como una tabla antes de mover nada.
3. Cuando lo apruebe, mueve las notas y añade enlaces desde el
   README del proyecto o del área.
4. Nunca borres una nota. Pon las descartadas en archive/inbox-rejects/.
5. Enumera todos los archivos que hayas tocado.

En Knowtarium

Sea cual sea la tarea, cada nota que Claude escribe o edita queda marcada en la barra lateral hasta que la abres, con sus cambios y un Undo a un clic. Para el mantenimiento de enlaces, los enlaces a notas que nadie ha escrito todavía aparecen en el grafo como fantasmas. Cuando Claude escribe una nota con citas en notas al pie, señala una en Knowtarium para ver la fuente que respalda la afirmación.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

Comandos integrados que conviene conocer en una bóveda:

Al cabo de unas semanas, un segundo cerebro con Claude Code contiene notas que no escribiste tú, y notas que sí escribiste pero que Claude ha editado desde entonces. Las dos cosas están bien, siempre que sepas cuál es cuál. Problemas típicos:

• Una pasada de limpieza reescribe una nota con la voz de Claude y se pierde la única salvedad que importaba.
• Un resumen da una fecha o una cifra que no está en la nota original.
• Un movimiento rompe enlaces, porque Claude movió el archivo con un comando de shell y nada actualizó los enlaces.
• Corriges un dato en una nota, y otras tres siguen con la versión antigua.
• Una nota que Claude escribió hace meses suena igual de segura que una que revisaste ayer.

El /rewind de Claude Code ayuda dentro de una sesión, con los límites que detalla la documentación de checkpoints: no sigue los archivos cambiados con comandos de shell (como mv o rm) y “no sustituye al control de versiones”. Para notas que guardas durante años, te conviene un paso de revisión que no dependa de la sesión.

Git es lo mínimo. Es gratis y funciona hoy: haz commit antes de una sesión, deja trabajar a Claude y luego lee el diff y quédate solo con lo que apruebes.

$ git status --short           # qué cambió mientras Claude trabajaba$ git diff --stat$ git diff projects/           # lee las ediciones, carpeta por carpeta$ git add -p                   # quédate con lo correcto, bloque a bloque$ git commit -m "inbox triage, reviewed"$ git restore .                # descarta el resto$ git clean -n                 # muestra los archivos nuevos que no guardaste

Algunos hábitos lo hacen rápido:

• Una tarea por sesión, un commit por tarea. Un diff de 4 archivos se lee fácil; uno de 60, no.
• Lee primero la lista de archivos cambiados. Cualquier cosa fuera de la carpeta por la que preguntaste merece una mirada más atenta.
• Comprueba los datos nuevos con la nota o el enlace que citan. Los datos sin cita son los que hay que cuestionar.
• Si algo hace commit de tu bóveda cada cierto tiempo, sus commits mezclarán tus ediciones con las de Claude. Haz commit a mano antes y después de las sesiones con Claude, o revisa después con git log -p.

Git te muestra un diff cuando te acuerdas de hacer commit. Knowtarium guarda el historial junto a las notas, y es el montaje que recomendamos cuando Claude escribe más de lo que te apetece leer en una terminal. Tus notas viven en un espacio de trabajo cifrado de extremo a extremo como un paquete OKF: markdown plano cuyo frontmatter registra quién escribió cada nota, quién la revisó, de dónde salen sus afirmaciones y cuándo se queda desfasada.

• Cada cambio va firmado y se puede deshacer. Los cambios de Claude se guardan al instante y se firman con su propia clave. Un punto en la barra lateral marca las notas que ha editado hasta que las abres, una línea bajo el título dice cuándo y enlaza a los cambios, y Undo recupera la versión anterior. El historial guarda cada versión durante el tiempo que configures, de un día a un año.
• La revisión está ahí cuando la quieres. Activa la revisión (“Ask me first”) en un espacio de trabajo o una carpeta, y los cambios de Claude ahí esperarán como diffs a que los apruebes o los rechaces. Tus propias ediciones ahí esperan hasta que pides a Claude que las revise, por ejemplo con “revisa las ediciones de hoy”, y Claude las compara con todo lo relacionado.
• Quién la escribió, en cada nota. Quién escribió una nota aparece en la parte superior. En las carpetas con revisión activada, también muestra quién la revisó, el grafo puede colorear las notas por nivel de confianza (unverified, machine-confirmed o human-reviewed) y una nota queda totalmente verificada cuando la han revisado una persona y un agente después de su último cambio.
• Nada se queda desfasado sin que te enteres. La página Stale and expiring lista las notas que han pasado su stale_after y las que vencen pronto.
• Claude trabaja por MCP. Knowtarium no llama a ninguna IA por sí mismo. Claude Code se conecta con npx knowtarium connect y recibe las convenciones con sus herramientas. Nosotros no podemos leer tus notas; Claude ve lo que lee.

Empezar con Knowtarium es gratis, con 500 MB de almacenamiento y un espacio de trabajo, y los planes Starter (5,99 US$ al mes) y Pro (11,99 US$ al mes) añaden almacenamiento y espacios de trabajo. Importa una bóveda de Obsidian a un espacio de trabajo y se convierte a OKF sin tocar lo que escribiste, y puedes exportarlo todo como markdown plano cuando quieras. Consulta la guía de migración y, para ver en qué se diferencian las dos apps, la página comparativa.

Nada de esto es exclusivo de Claude Code. Cualquier agente que sepa leer y escribir archivos en una carpeta puede llevar tu segundo cerebro. La diferencia principal es el nombre del archivo de instrucciones:

• Codex lee AGENTS.md, desde ~/.codex y desde las carpetas que hay entre la raíz de git y el lugar donde lo inicias, hasta un total de 32 KiB por defecto (documentación de Codex).
• Cursor también lee AGENTS.md, como alternativa más sencilla a sus archivos .cursor/rules (documentación de Cursor).
• Claude Code lee AGENTS.md cuando no hay CLAUDE.md, en las versiones recientes. Lo más portable es guardar tus reglas en AGENTS.md y dejar CLAUDE.md en una sola línea, @AGENTS.md, más lo que sea específico de Claude.

Así, todos los agentes siguen las mismas reglas de la bóveda, y la misma revisión los cubre a todos, en git o en el historial de Knowtarium. Nuestra guía sobre AGENTS.md para bases de conocimiento tiene una plantilla más completa. Si estás eligiendo una app para leer el resultado, la introducción al segundo cerebro con IA da una visión más amplia, y merece la pena leer el idea file de la LLM wiki de Karpathy para entender el patrón general.