Desarrollo

Cómo monté un segundo cerebro con IA y Obsidian (método Karpathy): plantilla, prompts y errores que me ahorré

08 Nov, 2026 • 35 min de lectura

Tenía una carpeta con cuatro libros en PDF, un par de resúmenes y varias notas sueltas. Lo de siempre: material bueno que nunca vuelves a consultar porque buscar algo dentro de 1.000 páginas da pereza. Quería que una IA me ayudara a estudiarlo, no solo a resumirlo: que encontrara las conexiones entre autores, que me avisara cuando dos de ellos se contradicen y que todo quedara en un formato que siga siendo mío dentro de diez años.

El resultado es una wiki de unas 95 notas en Markdown, enlazadas entre sí, que mantiene la IA y que yo abro con Obsidian. En este artículo cuento el proceso completo: de dónde salió la idea, la plantilla que usé, los prompts exactos, lo que salió mal, por qué descarté una base de datos y cómo aplicaría lo mismo en un puesto de trabajo.

El tema de mis libros era el trading, pero da igual: el método sirve igual para recetas, normativa fiscal, documentación técnica o los correos de un proyecto.

¿Quieres seguirlo paso a paso? En el paso 2 tienes un lote de material de prueba gratuito y legal (libros de dominio público y artículos de Wikipedia) para montar tu propia wiki de prueba en una tarde. Los ejemplos de código usan ese material.

Contenidos

1. De dónde sale la idea
2. La estructura
3. Paso 1: el CLAUDE.md (corto gana)
4. Paso 2: preparar el material de raw/
5. Paso 3: la primera ingesta, por fases
6. Paso 4: revisar la wiki (el “lint”)
7. Paso 5: síntesis, donde la wiki empieza a pensar
8. Paso 6: que lo revise otro (auditoría con contexto limpio)
9. Por qué Markdown y no una base de datos SQL
10. Copia de seguridad y control de versiones con git y GitHub
11. Beneficios que no esperaba
12. Limitaciones (y cómo las esquivé)
13. Caso de uso: la wiki de tu puesto de trabajo
14. Todos los prompts para arrancar
15. Lo que haría distinto si empezara hoy
16. Fuentes y enlaces
17. Atajo

De dónde sale la idea

El punto de partida fue este vídeo del canal AI for Work, Build Your Second Brain With Claude Code, Karpathy’s Method:

▶️ Ver el vídeo en YouTube

La idea, que el vídeo atribuye a Andrej Karpathy, es sencilla y muy potente:

1. Dejas tu material original en una carpeta raw/ que nadie toca nunca.
2. Un agente de IA (en mi caso Claude Code) lo lee y compila una wiki en Markdown: una nota por fuente, una por concepto y una por persona, todas enlazadas con [[wikilinks]].
3. Obsidian hace de “visor”: navegas por los enlaces, ves el grafo y buscas.
4. Cada vez que añades material nuevo, la IA lo integra con lo que ya existe en vez de empezar de cero.

La diferencia con “subir los PDFs a un chat” es que el conocimiento queda destilado y persistente. El chat se olvida al cerrar la pestaña; la wiki no.

La estructura

Esto es todo lo que hace falta. Sin plugins, sin base de datos, sin servidor:

mi-segundo-cerebro/
├── CLAUDE.md        ← instrucciones para la IA (se cargan solas en cada sesión)
├── INDEX.md         ← puerta de entrada: mapa de las notas principales
├── LOG.md           ← historial de ingestas, lo más reciente arriba
├── raw/             ← material original. SOLO LECTURA
├── sources/         ← una ficha por cada archivo de raw/
├── concepts/        ← ideas, métodos, teorías
├── entities/        ← personas, organizaciones, productos, obras
└── analyses/        ← síntesis entre varias fuentes (solo cuando las pides)

Dos detalles que parecen menores y no lo son:

• raw/ es sagrado. La IA nunca lo modifica. Es tu fuente de verdad: si una nota de la wiki dice algo raro, vuelves a raw/ y compruebas.
• El nombre del archivo es el título de la nota. concepts/Interés compuesto.md se enlaza como [[Interés compuesto]]. Así los enlaces funcionan igual en Obsidian, en GitHub y para la IA.

Paso 1: el CLAUDE.md (corto gana)

Claude Code lee automáticamente un archivo CLAUDE.md en la carpeta del proyecto al empezar cada sesión. Es donde van las reglas de la wiki.

Mi primer intento fue copiar un prompt larguísimo, lleno de frases del tipo “eres un agente autónomo de gestión de conocimiento cuyo objetivo es…”. Error: ese archivo se carga en cada sesión y se paga en tokens cada vez. Lo recorté a lo que de verdad cambia el comportamiento de la IA. Esta es la versión genérica que recomiendo, lista para copiar:

# Segundo cerebro (wiki)

Wiki personal en Markdown, compatible con Obsidian. Idioma: español.

## Estructura
- `raw/` — material original. **Solo lectura: nunca modificar, renombrar ni borrar.**
- `sources/` — una nota por archivo de raw/.
- `concepts/` — ideas, métodos, teorías.
- `entities/` — personas, organizaciones, productos, lugares, obras.
- `analyses/` — síntesis y comparativas (solo cuando lo pida, o si lo propones y acepto).
- `INDEX.md` — mapa de las notas principales por tema.
- `LOG.md` — registro de ingestas (lo más reciente arriba).

## Convenciones
- Nombre de archivo = título de la nota (`concepts/Interés compuesto.md`),
  enlazado como `[[Interés compuesto]]`.
- Frontmatter obligatorio:
  ```yaml
  ---
  type: source | concept | entity | analysis
  aliases: []
  tags: []
  raw: raw/archivo.pdf   # solo en sources
  created: YYYY-MM-DD
  updated: YYYY-MM-DD
  ---
  ```
- Source: resumen (5-10 líneas), ideas clave, citas relevantes,
  `## Conceptos` y `## Entidades` con wikilinks.
- Concept/Entity: definición breve, desarrollo, `## Relacionado` (wikilinks),
  `## Fuentes` (wikilinks a sources/).
- No inventar: todo lo que se afirme debe estar en raw/. Si algo no consta, se dice.

## Ingestar (cuando pida "ingestar" o "procesar raw")
1. Detectar pendientes: archivos de raw/ que no aparecen en el campo `raw:` de ninguna nota de sources/.
2. Si un PDF tiene un .txt o .md equivalente, leer solo el texto (mucho más barato) y listar ambos en `raw:`.
3. Si hay más de 3 pendientes: listarlos y proponer el plan antes de procesar. Procesar de uno en uno.
   Los documentos largos se leen por partes, no enteros de golpe.
4. Extraer conceptos y entidades clave. Solo crear nota si es central en la fuente o ya aparece
   en otra fuente; las menciones menores quedan como texto en la source.
5. Deduplicar: antes de crear una nota, buscar en concepts/ y entities/ por nombre y aliases.
   Si existe, actualizarla (y `updated`) en vez de crear otra.
6. Escribir: nota en sources/ → crear o actualizar concepts/ y entities/ →
   añadir la source en `## Fuentes` de cada nota tocada.
7. Índices: entrada en LOG.md (`## YYYY-MM-DD` + archivos creados/actualizados) y enlazar
   en INDEX.md solo las notas principales nuevas.
8. Resumen final: notas creadas/actualizadas y contradicciones detectadas entre fuentes.

## Consultar
Responder primero con la wiki, citando notas con [[wikilinks]]. Si falta algo, ir a raw/.
Si la respuesta tiene valor duradero, ofrecer guardarla en analyses/.

## Mantenimiento (cuando pida "revisar wiki")
Detectar notas huérfanas, wikilinks rotos, duplicados y conceptos mencionados sin nota propia.
Proponer arreglos; no aplicarlos sin confirmar.

Las tres reglas que más trabajo me ahorraron fueron:

• “Leer el .txt antes que el PDF”. Un PDF de 400 páginas cuesta muchísimos más tokens que su texto plano.
• “Deduplicar por nombre y aliases”. Sin ella acabas con Stop loss.md, Stop.md y Stop de protección.md diciendo lo mismo. Con ella, la segunda y la tercera pasan a ser aliases de la primera.
• “Proponer, no aplicar” en el mantenimiento. La IA es muy buena encontrando problemas y bastante mala decidiendo cuáles merecen la pena. Tú decides.

Paso 2: preparar el material de raw/

Material de prueba gratuito

Yo usé mis propios libros, pero para seguir esta guía no necesitas comprar nada. Este lote es gratuito, legal y del mismo tema (bolsa y especulación), y está pensado para ejercitar todo el proceso: hay textos largos y cortos, en inglés y en español, y una fuente secundaria (un artículo de blog):

Archivo	Qué es	Tamaño	Para qué sirve en la prueba
Reminiscences of a Stock Operator (Edwin Lefèvre, 1923)	Libro, dominio público (Project Gutenberg)	~620 KB	El “libro largo” de la fase 2: obliga a leer por partes
Psychology of the Stock Market (G. C. Selden, 1912)	Libro, dominio público	~130 KB	Libro corto
Extraordinary Popular Delusions and the Madness of Crowds, vol. 1 (Charles Mackay, 1841)	Libro, dominio público	~590 KB	El clásico sobre burbujas (Misisipi, Mares del Sur, tulipanes): segundo libro largo, y conecta con el artículo “Burbuja económica” de Wikipedia
Análisis técnico · Gráfico de velas · Burbuja económica	Artículos de Wikipedia en español (licencia CC BY-SA)	10-25 KB	Notas cortas de la fase 1, en español
Mi artículo sobre las mechas de las velas	Artículo de blog (mío)	~8 KB	Fuente secundaria: comprueba que la wiki la etiqueta como fiabilidad/secundaria

Los libros de Project Gutenberg son de dominio público en EE. UU.; si estás en otro país, Gutenberg recomienda comprobar la ley local antes de descargarlos.

Para descargarlo todo de una vez en raw/:

mkdir -p mi-segundo-cerebro/raw && cd mi-segundo-cerebro/raw

# Libros de dominio público (Project Gutenberg), ya en texto plano: no hace falta extraer nada
curl -L -o lefevre-reminiscences-of-a-stock-operator.txt https://www.gutenberg.org/cache/epub/60979/pg60979.txt
curl -L -o selden-psychology-of-the-stock-market.txt     https://www.gutenberg.org/cache/epub/75570/pg75570.txt
curl -L -o mackay-popular-delusions-vol1.txt         https://www.gutenberg.org/cache/epub/636/pg636.txt

# Artículos de Wikipedia en español, en wikitexto (la IA lo lee sin problema)
curl -L -o wikipedia-analisis-tecnico.txt  "https://es.wikipedia.org/w/index.php?title=An%C3%A1lisis_t%C3%A9cnico&action=raw"
curl -L -o wikipedia-grafico-de-velas.txt  "https://es.wikipedia.org/w/index.php?title=Gr%C3%A1fico_de_velas&action=raw"
curl -L -o wikipedia-burbuja-economica.txt "https://es.wikipedia.org/w/index.php?title=Burbuja_econ%C3%B3mica&action=raw"

El artículo del blog guárdalo con Obsidian Web Clipper (ver más abajo). En total son 7 archivos: más de 3, así que en la primera ingesta la IA te propondrá un plan antes de empezar, como me pasó a mí.

Tus propios PDFs

Si usas tus propios PDFs y tienen texto (no son escaneos), extráelo una vez y guarda el .txt junto al PDF. En Linux:

# Instala poppler-utils si no lo tienes: sudo apt install poppler-utils
cd raw/
for f in *.pdf; do pdftotext -layout "$f" "${f%.pdf}.txt"; done

Para artículos web, Obsidian Web Clipper (o cualquier “guardar como Markdown”) te deja un .md limpio con la URL de origen en el frontmatter. De hecho, uno de los últimos archivos que ingerí fue mi propio artículo sobre cómo leer las mechas de las velas.

Y un consejo que aprendí tarde: si un archivo de raw/ lo generó otra IA (un resumen, una respuesta de chat), márcalo como fuente secundaria. Yo tenía tres notas así y la wiki las etiquetó con fiabilidad/secundaria hasta poder contrastarlas con los libros. Una de ellas usaba un término clave, “trampa”, que luego resultó no aparecer en ninguno de los dos libros del autor: el concepto sí estaba, la palabra no. Sin esa etiqueta lo habría dado por bueno.

Paso 3: la primera ingesta, por fases

Con 13 archivos pendientes, la propia regla 3 hizo que la IA me propusiera un plan antes de tocar nada. Lo dividimos así:

• Fase 1, notas cortas (5 archivos): salen las primeras 5 fichas, 8 entidades y 12 conceptos. Rápido y barato: sirve para que la wiki tenga “esqueleto”.
• Fase 2, libros completos, uno por sesión (4 libros de entre 142 y 437 páginas): cada libro añade fichas y, sobre todo, actualiza las notas que ya existían. El segundo libro, por ejemplo, creó 9 conceptos nuevos y actualizó 12.

Insistí en leer los libros enteros, incluidos prólogos y capítulos introductorios. Mi intuición era que ahí está el marco que da sentido al resto, y acerté: varias de las conexiones más útiles salieron de capítulos que un resumen rápido se habría saltado.

Lo que la ingesta hizo bien sin que yo lo pidiera:

• Detectar contradicciones entre autores. Un autor compra cuando el precio rompe a máximos con volumen; otro compra cuando el precio cae, engaña a los vendedores y se gira. Cada uno defiende lo suyo en su libro. La wiki lo señaló en el resumen de la ingesta.
• Corregir atribuciones falsas. Una nota previa daba por hecho que cierto trader aparecía entrevistado en uno de los libros. Al leerlo entero, cero menciones. La nota se corrigió y quedó constancia en el LOG.
• Avisar de lo que no podía verificar. Cuando añadía contexto posterior a la fecha de un libro, lo marcaba como “no verificado con raw/”.

Así queda una entrada del LOG.md después de una fase. El ejemplo usa el material de prueba; las notas concretas que salgan en tu wiki serán otras, pero el formato es este:

## 2026-11-10 — Fase 2.1: Lefèvre, *Reminiscences of a Stock Operator* (lectura completa)
**Procesados**: lefevre-reminiscences-of-a-stock-operator.txt

**Creados**
- sources (1): Lefèvre - Reminiscences of a Stock Operator
- entities (…): Larry Livingston · Edwin Lefèvre · ...
- concepts (…): Línea de menor resistencia · Bucket shops · Piramidación · ...

**Actualizados**: Análisis técnico · Burbuja económica · ...

**Pendiente**: Mackay *Extraordinary Popular Delusions* (vol. 1) → Selden *Psychology of the Stock Market*.

Ese “Pendiente” es lo que hace que la siguiente sesión, aunque empiece sin memoria, sepa exactamente por dónde seguir.

Paso 4: revisar la wiki (el “lint”)

Cuando terminó la ingesta pedí una revisión. La IA buscó notas huérfanas, enlaces rotos, duplicados, alias que chocan y conceptos que se mencionan mucho pero no tienen nota. Encontró, entre otras cosas:

• Listas mal formateadas en 8 notas.
• Sinónimos que merecían ser alias (Shakeout → Trampa de mercado; Stop → Gestión del riesgo).
• Conceptos citados en varias notas sin nota propia (Análisis de volumen, Soporte y resistencia).
• Y una contradicción repartida en cinco notas sin ninguna síntesis.

Ojo con un detalle: en una segunda revisión, la IA me propuso crear una nota “Doble suelo”… que ya existía como alias de otra nota. La propuesta salía de una lista suya antigua y no del análisis real. Lo detectó ella misma al ir a aplicarlo, pero es la prueba de por qué la regla es proponer y no aplicar sin confirmar.

Paso 5: síntesis, donde la wiki empieza a pensar

La contradicción repartida en cinco notas me pareció lo más valioso de todo el lint, así que pedí una nota de síntesis en analyses/: una tabla con las dos escuelas, dónde coinciden (más de lo que parecía: las dos esperan una confirmación antes de entrar), dónde discrepan de verdad (stop, promediado a la baja, comprar caro o barato) y en qué situación de mercado conviene cada una. Todo enlazado: unas 35 notas apuntan o son apuntadas desde la síntesis.

Al repasarla, la IA corrigió una frase suya que generalizaba de más: afirmaba que una estadística valía “para todas las figuras” cuando la fuente solo la daba para una. Las síntesis son el sitio donde más fácil es exagerar, porque mezclan fuentes. Revísalas con lupa.

Como experimento, convertimos las dos escuelas en reglas mecánicas y las probamos con datos históricos. El resultado (ninguna de las dos, simplificada, batía a comprar cualquier día) es exploratorio y no demuestra nada sobre los autores, pero ilustra algo importante: una buena wiki no solo resume, genera preguntas que puedes comprobar.

Paso 6: que lo revise otro (auditoría con contexto limpio)

El agente que ha escrito la wiki tiende a creerse lo que ha escrito. Lo más útil que hice al final fue lanzar un segundo agente, sin el contexto de la conversación, con un encargo acotado: coger las afirmaciones con cifras de las notas de análisis y contrastarlas con raw/, indicando archivo y línea.

De más de 20 afirmaciones, la gran mayoría salieron verificadas con su línea exacta. Pero encontró una exageración que se nos había escapado a los dos: la nota decía que un autor “exige” cierta condición, y el libro dice que “normalmente” ocurre. Es el tipo de error que ningún test detecta y que, repetido, convierte una wiki en un teléfono roto.

El prompt está más abajo, en la sección de prompts.

Por qué Markdown y no una base de datos SQL

Fue la primera decisión de diseño y la tengo clarísima. Lo pensé en serio porque SQL ofrece consultas potentes, pero:

1. Obligas a la IA a traducir todo. Un modelo de lenguaje lee y escribe texto de forma nativa. Con SQL, cada ingesta pasa a ser “lee el libro → diseña un esquema → conviértelo en INSERT → no rompas las claves foráneas”, y cada consulta, “traduce la pregunta a SQL → interpreta filas”. Son más tokens, más pasos y más sitios donde equivocarse. Y cuando el esquema se queda corto (y se queda), toca migrar.
2. Git no sirve para un archivo de base de datos. Un .db de SQLite es un binario: git no puede mostrarte qué cambió, no puede fusionar los cambios de dos personas y guarda una copia entera del archivo en cada commit. Eso significa que pierdes a la vez la copia de seguridad con historial y la colaboración. Con Markdown, cada cambio es una línea en un diff legible, puedes revertir una sola nota y dos personas pueden trabajar a la vez con pull requests.
3. No hay visor. Obsidian, GitHub, VS Code o el bloc de notas leen Markdown. Un .db necesita un programa específico.

¿Cuándo sí usaría SQL? Para datos numéricos masivos y estructurados (precios, transacciones, métricas). La wiki puede hablar de esos datos; no debería contenerlos.

Copia de seguridad y control de versiones con git y GitHub

Precisamente porque todo es texto, la copia de seguridad es trivial. Una vez:

cd mi-segundo-cerebro
git init
cat > .gitignore <<'EOF'
# Estado de la interfaz de Obsidian: cambia cada vez que abres el vault
.obsidian/workspace*.json
EOF
git add . && git commit -m "Wiki inicial"

# Repositorio PRIVADO en GitHub (requiere la CLI gh y haber hecho gh auth login)
gh repo create mi-segundo-cerebro --private --source=. --push

Y después de cada ingesta:

git add . && git commit -m "Ingesta: <nombre de la fuente>" && git push

El LOG.md te cuenta qué se ingirió; git te deja ver exactamente qué cambió en cada nota y deshacerlo si la IA metió la pata. Si los PDFs de raw/ pesan mucho o tienen derechos de autor, puedes excluirlos del repositorio y guardar solo los .txt o solo la wiki.

Beneficios que no esperaba

• Compatibilidad con cualquier IA. Markdown es el idioma nativo de los modelos de lenguaje. La misma carpeta funciona con Claude Code, con otros agentes de terminal y con herramientas como NotebookLM. Truco: otros agentes buscan su propio archivo de instrucciones (por ejemplo AGENTS.md); un enlace simbólico ln -s CLAUDE.md AGENTS.md evita mantener dos copias.
• Compatibilidad con otras fuentes. Cualquier cosa que puedas exportar a texto (webs, correos, actas, transcripciones de vídeo) entra por raw/ con el mismo proceso.
• Detecta lo que tú no ves. Las contradicciones entre autores y las afirmaciones sin respaldo salen solas.
• Copia de seguridad e historial con git, gratis.
• Traspaso de conocimiento. Esto es lo que más me hizo pensar en el trabajo: una persona nueva puede empezar por INDEX.md y tener el mapa completo el primer día. Lo desarrollo en el caso de uso del final.
• Independencia. Si mañana dejo de usar Obsidian o cambio de IA, mis notas siguen siendo archivos de texto legibles.

Limitaciones (y cómo las esquivé)

Limitación	Qué pasa	Workaround
Explosión de archivos	Con correos o chats es facilísimo llegar a miles de archivos en raw/ y cientos de notas casi vacías.	Un .md por conversación (hilo), no por mensaje. Y en la wiki, una nota por tema o proyecto, no por correo. Ingiere solo los hilos que contienen una decisión o un procedimiento.
Coste en tokens	Leer libros enteros y repasar la wiki completa es caro.	.txt en vez de PDF, libros por partes, un CLAUDE.md corto y fases: primero lo corto, luego lo largo.
La IA exagera o generaliza	“Exige” donde el libro dice “normalmente”; “todas las figuras” donde la fuente habla de una.	Regla “no inventar” en el CLAUDE.md, raw/ intacto para comprobar y una auditoría con otro agente de vez en cuando.
Material de raw/ generado por IA	Se cuela como si fuera fuente primaria.	Etiquetarlo como fiabilidad/secundaria y contrastarlo.
El contexto de la sesión se agota	En ingestas largas la conversación se resume y se pierde detalle.	LOG.md con “Pendiente” e INDEX.md: son la memoria entre sesiones. Un libro por sesión.
Las herramientas externas no entienden los enlaces	NotebookLM no sigue [[wikilinks]] ni conoce los aliases; además limita el número de fuentes por cuaderno.	Concatenar las notas en 4-5 archivos (uno por carpeta), con cada nota bajo su # Título y una línea “También llamado: …” con sus alias.
Copias que divergen	Si copias la wiki a otro sitio y sigues editando las dos, acabarán diciendo cosas distintas.	Una sola copia viva. Las demás son de solo lectura o se borran.
Privacidad	Correos y documentos de trabajo contienen datos personales y confidenciales.	Repositorio privado, IA aprobada por tu empresa y nada de datos personales innecesarios en entities/.

Caso de uso: la wiki de tu puesto de trabajo

Aquí es donde creo que el método brilla de verdad. Todos hemos heredado un puesto con un “ya te lo irá contando fulano” y una carpeta compartida caótica. Y todos nos hemos ido de un puesto sabiendo que medio conocimiento se iba con nosotros.

La propuesta es una wiki del puesto, no de la persona: la mantienes tú con ayuda de la IA mientras trabajas y se la entregas a quien venga después.

La estructura

wiki-puesto/
├── CLAUDE.md
├── INDEX.md              ← mapa general
├── ONBOARDING.md         ← "tu primera semana": qué leer y en qué orden
├── LOG.md
├── raw/
│   ├── hilos/            ← UN .md POR CONVERSACIÓN de correo o chat
│   ├── actas/            ← reuniones
│   ├── docs/             ← manuales, contratos, especificaciones
│   └── tickets/          ← incidencias exportadas
├── procesos/             ← cómo se hace cada tarea recurrente, paso a paso
├── sistemas/             ← herramientas, accesos (¡nunca contraseñas!), dónde está cada cosa
├── contactos/            ← clientes, proveedores, equipos: qué llevan y cómo tratarlos
├── decisiones/           ← qué se decidió, cuándo, por qué y qué alternativas se descartaron
└── problemas-conocidos/  ← síntoma → causa → solución

La carpeta decisiones/ es la que más valor tiene a largo plazo. Responde a la pregunta que nadie sabe contestar seis meses después: “¿por qué se hace así?”.

El formato de un hilo en raw/hilos/

El truco contra la explosión de archivos: cada conversación, entera, en un único Markdown. Ni un archivo por correo ni los adjuntos sueltos:

---
asunto: "Cambio de proveedor de transporte para envíos a Canarias"
participantes: [Ana (logística), Proveedor X, yo]
inicio: 2026-09-02
fin: 2026-09-18
estado: cerrado        # abierto | cerrado
---

## 2026-09-02 — Ana
Los envíos a Canarias con el proveedor actual tardan 9-12 días...

## 2026-09-05 — Proveedor X
Podemos ofrecer 4-5 días con despacho de aduanas incluido...

## 2026-09-18 — yo
Confirmado: a partir del 1 de octubre, Canarias va con Proveedor X.
Motivo: plazo y aduana incluida. Coste +8 % asumido por dirección.

Una conversación de 40 correos se queda en un solo archivo, y la IA ve el hilo completo, con su conclusión, en lugar de 40 fragmentos sin contexto. La mayoría de clientes de correo permiten exportar o imprimir un hilo entero; si no, pide a la IA que te convierta el .eml o el texto copiado a este formato.

El CLAUDE.md del puesto

# Wiki del puesto: <nombre del puesto>

Conocimiento operativo del puesto, para mí y para quien me sustituya. Idioma: español.

## Reglas
- `raw/` es solo lectura.
- **Nunca** guardar contraseñas, tokens ni datos personales innecesarios
  (teléfonos personales, DNI, salud...). Para accesos: dónde se piden, no cuáles son.
- No inventar: cada afirmación debe salir de raw/. Si un proceso tiene huecos, decirlo.

## Tipos de nota
- `procesos/`: objetivo · cuándo se hace · pasos numerados · errores típicos · a quién preguntar.
- `decisiones/`: fecha · decisión · motivo · alternativas descartadas · hilo de origen.
- `problemas-conocidos/`: síntoma · causa · solución · cuántas veces ha pasado.
- `contactos/`: qué lleva · para qué se le escribe · particularidades.
- `sistemas/`: para qué sirve · cómo se pide acceso · procesos que lo usan.

## Ingestar (cuando pida "ingestar")
1. Pendientes: archivos de raw/ que no aparecen en ninguna nota.
2. De cada hilo, extraer solo: decisiones, procesos, problemas resueltos y contactos nuevos.
   Lo demás (saludos, seguimiento, "ok, gracias") se ignora.
3. Actualizar notas existentes antes que crear nuevas.
4. Si un hilo cambia un proceso o anula una decisión anterior, actualizar la nota
   y dejar constancia del cambio con la fecha.
5. LOG.md y, si hay notas principales nuevas, INDEX.md y ONBOARDING.md.

## Mantenimiento ("revisar wiki")
Además de enlaces rotos y duplicados: procesos sin actualizar en 6 meses, decisiones
sin motivo y problemas conocidos sin solución. Proponer, no aplicar.

Prompts del día a día en el trabajo

Ingesta los hilos nuevos de raw/hilos/ de esta semana.

¿Cómo se gestiona una devolución de un cliente de Canarias? Responde con la wiki
y dime qué nota o hilo lo respalda.

Prepara ONBOARDING.md para alguien que empieza el lunes en este puesto: los 10 procesos
más frecuentes, los sistemas a los que necesita acceso y las 5 decisiones que debe conocer.

Me voy de vacaciones dos semanas. Haz un resumen de los hilos abiertos con su estado
y el siguiente paso de cada uno.

Cuando te vayas del puesto, la persona nueva recibe la carpeta (o el acceso al repositorio privado) y empieza por ONBOARDING.md. Y puede preguntarle a la IA sobre la wiki desde el primer día, en lugar de esperar a que alguien tenga un hueco.

Todos los prompts para arrancar

En el orden en que los usé. Los de Claude Code se escriben tal cual en la terminal, dentro de la carpeta de la wiki.

1. Crear la estructura (con el CLAUDE.md ya guardado en la carpeta):

Lee CLAUDE.md, mira lo que hay ya en el directorio y crea las carpetas que falten.
No toques raw/.

2. Primera ingesta:

ingestar

Si hay más de 3 pendientes, te propondrá un plan. El mío fue:

Haz la fase 1 (notas cortas). La segunda, con los libros, hazla completa:
los prólogos y capítulos introductorios pueden ser clave para entender la materia.

3. Seguir hasta el final sin ir libro a libro:

Sí, sigue hasta completar todos los libros y luego revisa la wiki.

4. Revisión:

revisa wiki

5. Aplicar lo propuesto (o solo una parte):

Aplica todo menos el punto 4.

6. Síntesis de una contradicción:

La contradicción entre <autor o escuela A> y <autor o escuela B> está repartida en varias notas sin síntesis.
Haz una nota en analyses/ con los puntos en común, las discrepancias reales y cuándo aplica
cada una. Todo enlazado. Sin afirmar nada que no esté en raw/.

7. Consultar:

¿Qué dicen mis fuentes sobre <tema>? Responde primero con la wiki y cita las notas.

Con el material de prueba, por ejemplo:

¿Qué dicen Selden y Lefèvre sobre la psicología del especulador? ¿Encaja con las burbujas que describe Mackay?
Responde primero con la wiki y cita las notas.

8. Auditoría con otro agente (en Claude Code, pídele que lance un subagente; en otra herramienta, abre una sesión nueva):

Lanza un auditor separado, de solo lectura. Que extraiga todas las afirmaciones con cifras
o atribuidas a un autor de las notas de analyses/ y las contraste con raw/ (grep en los .txt),
clasificando cada una como VERIFICADA (archivo:línea), DISCREPA (qué dice raw/) o SIN RESPALDO.
Que no modifique nada.

9. Exportar para NotebookLM u otra herramienta:

Genera en export/ un archivo por carpeta (fuentes, conceptos, entidades, análisis) con cada
nota bajo un encabezado "# Título" y una línea "También llamado: <aliases>". No modifiques la wiki.

Lo que haría distinto si empezara hoy

1. Git desde el minuto uno, no al final.
2. Etiquetar desde el principio cualquier archivo de raw/ que no sea fuente primaria.
3. Pedir la auditoría con otro agente antes, después de la primera síntesis, no al final.
4. No subir raw/ y la wiki juntos a NotebookLM: el modelo los trataría como dos fuentes independientes que dicen lo mismo y citaría una u otra indistintamente. O la wiki (para preguntar sobre tu síntesis) o los originales (para verificar).

Fuentes y enlaces

• Vídeo original: Build Your Second Brain With Claude Code, Karpathy’s Method, canal AI for Work.
• Obsidian: el editor y visor de Markdown que uso para navegar la wiki.
• Claude Code: el agente de terminal que mantiene la wiki.
• NotebookLM: alternativa para preguntar sobre los documentos, con las limitaciones descritas arriba.
• Material de prueba: Project Gutenberg (libros de Lefèvre, Mackay y Selden) y Wikipedia en español.

Atajo

Te dejo un prompt para pegar en el otro proyecto. Rellena los tres huecos entre <> al principio. Está sacado de mi wiki curada, sin lo que es propio de mi proyecto (CLI, PLAN, capital). He añadido lo que hemos aprendido en las ingestas: niveles de autoridad, citas por línea comprobadas y lectura dirigida de libros grandes.

Crea una wiki de conocimiento en blanco dentro de este proyecto, en `<ruta>/wiki/`, siguiendo el método de Karpathy (segundo cerebro). Debe funcionar como vault de Obsidian autocontenido.

- Temática: <tema>
- Idioma de las notas: <idioma>
- Para qué se va a usar: <p. ej. "decisiones de diseño del producto", "investigación para un libro">

## Qué crear ahora
1. La estructura: `raw/`, `sources/`, `concepts/`, `entities/`, `analyses/`, `INDEX.md`, `LOG.md` y `CLAUDE.md`. Sin notas de contenido: la wiki empieza vacía.
2. `wiki/CLAUDE.md` con las reglas de abajo.
3. `INDEX.md` con la cabecera "Empieza aquí" y secciones vacías.
4. `LOG.md` con "_Lo más reciente arriba._" y una entrada de creación.
5. Una sección corta en el `CLAUDE.md` raíz del proyecto que apunte a `wiki/CLAUDE.md`. Debe incluir la tabla de niveles de autoridad, de momento vacía.
6. Enséñame los ficheros antes de hacer commit.

## Reglas para wiki/CLAUDE.md

### 1. Generales
- `raw/` es de solo lectura: nunca modificar, renombrar ni borrar nada ahí, ni siquiera para corregir una errata en el nombre. Las citas van por ruta y número de línea, y renombrar o reextraer las rompe. Nunca sobrescribir un `.txt` existente.
- `raw/` es también la bandeja de entrada: el material nuevo se deja ahí para ingerir. Para consultar se empieza por `INDEX.md`, no por `raw/`.
- Formato Obsidian nativo: `[[Wikilinks]]` para enlaces internos y tags en el frontmatter.
- Incremental: nunca reconstruir la wiki desde cero; lo nuevo se integra con lo existente.
- Sin scripts sueltos dentro de la wiki.

### 2. Autoridad de las fuentes
Estar en `raw/` no da autoridad. Cada ficha lleva su nivel:
- **Alto**: libro publicado o notas propias con URL por cifra. Tag `fuente/libro` o `fuente/notas-web`.
- **Medio**: libro de divulgación o crónica sin rigor; contrastar las cifras antes de usarlas.
- **Bajo**: enciclopedia sin autor, blog, resumen, texto generado por IA. Tag `fiabilidad/secundaria`.
- Un relato novelado se cita como el personaje del libro, no como si fueran palabras de la persona real.
- El material nuevo entra en Bajo hasta verificarlo contra una fuente Alta.
- La wiki es una síntesis escrita por un LLM y puede exagerar ("exige" donde la fuente dice "normalmente"). Toda cifra o regla que vaya a una decisión importante lleva la cita de la wiki **y** la de `raw/` con línea y nivel.
- Al dar de alta una fuente nueva, añadirla a la tabla de autoridad del `CLAUDE.md` raíz, con el visto bueno del owner.

### 3. Estructura
- `sources/`: una ficha por documento de `raw/`.
- `concepts/`: ideas, teorías, métodos.
- `entities/`: personas, libros, empresas, herramientas.
- `analyses/`: síntesis entre fuentes, solo cuando el owner lo pida o lo acepte.

### 4. Convenciones
- Nombre de fichero = título de la nota.
- Plantilla obligatoria:
```
---
tipo: fuente | concepto | entidad | analisis
aliases: []
tags:
  - categoria/subcategoria
fecha: YYYY-MM-DD
actualizado: YYYY-MM-DD
fuente_original:        # solo en tipo fuente
  - "[[raw/fichero.ext]]"
---
# Título
## Resumen ejecutivo
## Contenido principal
## Conexiones
## Fuentes              # en conceptos, entidades y análisis
```
- En las fichas de fuente, cada afirmación lleva su número de línea, `(l. N-M)`. Comprobar las líneas con `grep -n` antes de dar la ficha por buena.
- Las afirmaciones que no salen de `raw/` (conocimiento previo del asistente, juicio propio) se marcan `[JUICIO]` o "no verificado en raw/".

### 5. Ingerir (cuando pida "ingiere" o "procesa raw")
1. **Detectar pendientes**: ficheros de `raw/` que no aparecen en el `fuente_original` de ninguna ficha.
2. **Duplicados de formato**: si un PDF tiene un `.txt` o `.md` equivalente, leer solo el texto y listar ambos en `fuente_original`. El PDF solo se lee si no hay texto, salvo para figuras.
3. **Ficheros con fin de línea Windows**: quitar `\r` antes de procesarlos con awk o grep.
4. **Más de 3 pendientes o algún libro largo** (más de unos 100 KB): parar, listarlos con tamaño y plan, y preguntar antes de procesar. Opciones a proponer:
   - leerlo entero por partes;
   - leer solo los capítulos pertinentes;
   - lectura dirigida con `grep` de los pasajes clave.

   Dar el coste aproximado en tokens. Los ficheros cortos se pueden procesar mientras tanto.
5. **Extraer** conceptos y entidades. Crear nota solo si es central en la fuente o ya aparece en otra; las menciones menores quedan como texto en la ficha.
6. **Deduplicar**: buscar por nombre y por `aliases` en `concepts/` y `entities/`. Si existe, actualizarla (y su `actualizado`) en vez de crear otra.
7. **Escribir**:
   - la ficha en `sources/`;
   - las notas nuevas o actualizadas;
   - la ficha en `## Fuentes` de cada nota tocada.
8. **Comprobar enlaces**: ningún `[[...]]` debe quedar sin nota.
9. **Índices**: entrada en `LOG.md` con la fecha y lo creado o actualizado. Enlazar en `INDEX.md` solo las notas principales.
10. **Resumen final**:
    - notas creadas y actualizadas;
    - contradicciones entre fuentes;

### 6. Consultar
Responder primero con la wiki, citando las notas con `[[wikilinks]]`. Si la respuesta lleva a una decisión importante o a código, añadir la cita de `raw/` con línea y nivel. Si la respuesta tiene valor duradero, ofrecer guardarla en `analyses/`.

### 7. Mantenimiento (cuando pida "revisa la wiki")
Detectar:
- notas huérfanas;
- wikilinks rotos;
- duplicados;
- conceptos mencionados sin nota propia;
- afirmaciones sin línea de `raw/`.

Proponer arreglos y no aplicarlos sin confirmación.

Categorías: Desarrollo

Etiquetas: inteligencia artificial claude code obsidian segundo cerebro markdown productividad