OKF Second Brain: Convertí Mi Configuración de Claude y Por Fin Dejó de Olvidar
El momento en que abandoné mi viejo second brain llegó un martes, viendo a Claude crear un archivo llamado pricing-v2-FINAL.md seis carpetas adentro — justo al lado del pricing.md que había escrito tres semanas antes y aparentemente olvidó que existía.
Dos archivos. El mismo conocimiento. Contradiciéndose mutuamente. Ambos con confianza "correctos."
Esa es la podredumbre que se instala en toda base de conocimiento personal construida como la mía: una maraña de notas markdown sostenidas por un heroico archivo Claude.md haciendo el trabajo de un índice, un bibliotecario y una memoria al mismo tiempo. Funciona maravillosamente con treinta archivos. Se desmorona silenciosamente con trescientos. Mi agente no era tonto — simplemente no tenía forma confiable de saber qué ya existía antes de escribir algo nuevo. Así que re-derivaba, re-resumía y duplicaba, sesión tras sesión.
Este es exactamente el problema para el que se construyó el Open Knowledge Format de Google, y durante un fin de semana en junio de 2026 reconstruí toda mi configuración como un OKF second brain para averiguar si el formato realmente lo arregla o solo renombra el desorden. Voy a guiarte por la conversión real — la cirugía de carpetas, el skill de conversión en el que me apoyé, la única línea que agregué a Claude.md que lo cambió todo, qué se rompió, y el honesto antes y después. Si tienes una base de conocimiento markdown que Claude trata como un cajón de sastre, este es el camino de salida.
Asumo que ya sabes aproximadamente qué es OKF. Si no, lee primero mi primera mirada como desarrollador al Open Knowledge Format — cubre la especificación desde cero. Este artículo es la parte que viene después: Ya tengo un second brain. ¿Y ahora qué?
Por Qué Mi Claude Second Brain Chocó Contra un Muro
Déjame describir la configuración, porque la tuya probablemente rima con ella.
Había estado ejecutando una base de conocimiento personal durante aproximadamente un año — del tipo que documenté en mi Claude Code second brain build. Archivos markdown, carpetas anidadas por proyecto y tema, y un pesado Claude.md en la raíz diciéndole a Claude dónde vivían las cosas y cómo comportarse. Manuales de clientes. Lógica de precios. Fragmentos de código. Notas de reuniones. Heurísticas duramente ganadas que nunca quise volver a aprender.
El sistema tenía cuatro modos de fallo, y empeoraban a medida que crecía.
Claude no podía saber si algo ya existía. Sin un mapa legible por máquina, la única forma para que el agente verificara "¿ya tengo una nota sobre la política de reembolso?" era buscar nombres de archivos y recorrer carpetas. Eso es lento, hambriento de tokens y poco confiable. Así que frecuentemente no verificaba — y escribía un duplicado. Ese momento de pricing-v2-FINAL.md no fue algo aislado.
La búsqueda era un impuesto. Cada recuperación significaba que el agente se desplegaba por directorios anidados, abría archivos para ver si eran relevantes, y quemaba contexto en callejones sin salida. Cuanto más profundo el árbol de carpetas, más pesado el impuesto.
Nada era portable. Mi second brain estaba hecho a medida para mi flujo de trabajo y mi Claude.md. No podía pasárselo a un compañero de equipo, montarlo en otro agente, o compartir una parte sin que el todo perdiera significado. Era un dialecto privado, no un idioma.
El Claude.md era portante de manera peligrosa. Toda la estructura vivía en la prosa de un archivo. Si ese archivo se desincronizaba con las carpetas reales — y siempre lo hacía — el agente navegaba con un mapa obsoleto.
Ninguno de estos son problemas exóticos. Es lo que toda second brain no estandarizada enfrenta pasado cierto tamaño. La estructura que se sentía como libertad al principio se convirtió en lo que la estrangulaba. Había intentado arreglarlo con mejor disciplina de carpetas y un Claude.md más largo. Eso es tratar un problema estructural con fuerza de voluntad. No dura.
Lo que realmente necesitaba era una forma estándar — una en la que el agente pudiera confiar sin que yo guiara cada navegación. Esa es la apuesta que hace OKF. Hora de probarla.
Cómo Se Ve Realmente un OKF Second Brain
Aquí está el reencuadre que hizo clic para mí: OKF no te pide agregar herramientas. Te pide acordar una forma. Y la forma es casi insultantemente simple — archivos de concepto markdown con front matter YAML, agrupados en un bundle, encabezados por un index.md que actúa como mapa.
Mi viejo second brain organizaba por proyecto. Mi OKF second brain organiza por concepto, con una separación dura que el gist de LLM Wiki de Karpathy me martilló: mantén el material fuente crudo separado del conocimiento sintetizado. Transcripciones crudas, páginas scrapeadas y notas vertidas viven en /raw. Los conceptos limpios y legibles por el agente viven en la wiki misma. El agente lee /raw, extrae conceptos y escribe páginas estructuradas — nunca te sirve la pila cruda directamente.
La nueva estructura se ve así:
second-brain/
├── index.md # el mapa: cada concepto, una línea cada uno
├── log.md # historial append-only de cambios
├── raw/ # material fuente, sin tocar
│ ├── call-2026-06-18.md
│ └── scraped-pricing-research.md
├── clients/
│ ├── index.md # sub-mapa para esta carpeta
│ ├── onboarding-sequence.md
│ └── escalation-playbook.md
└── business/
├── index.md
├── pricing-logic.md
└── positioning.md
Cada archivo de concepto lleva front matter que el agente lee antes de abrir el cuerpo:
---
type: playbook
title: Secuencia de Onboarding de Clientes
description: Los pasos exactos que ejecuto cuando un nuevo cliente de automatización IA firma.
tags: [onboarding, proceso, clientes]
timestamp: 2026-06-18
---
# Secuencia de Onboarding de Clientes
Cuando un nuevo cliente firma, ejecuto estos pasos en orden. Cada paso tiene un
disparador y una definición de terminado...
El campo type es el único que OKF v0.1 requiere estrictamente. Todo lo demás — title, description, tags, timestamp — es recomendado. Pero la description es el héroe silencioso aquí, y te mostraré por qué en la sección de resultados. Es lo que permite a un agente decidir si abrir un archivo sin abrirlo.
El index.md es donde una carpeta plana se convierte en un grafo navegable:
---
type: index
title: Second Brain — Root Index
---
# Second Brain Index
## clients/
- **onboarding-sequence** — pasos ejecutados cuando un nuevo cliente firma
- **escalation-playbook** — cómo manejar un cliente insatisfecho a mitad del proyecto
## business/
- **pricing-logic** — cómo precio encargos de automatización IA
- **positioning** — a quién sirvo y a quién rechazo
Esa descripción de una línea por concepto es todo el truco. El agente lee el índice, ve treinta descripciones y decide cuáles dos archivos realmente necesita — y luego abre solo esos. Es revelación progresiva, el mismo principio que hace eficientes a los skills de Claude bien construidos. El índice es el foco. Los conceptos son a lo que apunta.
Esta es la diferencia estructural entre un OKF second brain y la pila que tenía antes: el mapa es un archivo, no prosa enterrada en Claude.md, y vive junto a lo que describe. Cuando agrego un concepto, actualizo su índice local. El mapa y el territorio permanecen sincronizados porque son vecinos.
Ese es el objetivo. Ahora la migración.
Cómo Convertí Mi Second Brain a OKF
Tomé dos pasadas a propósito, porque quería sentir el formato a mano antes de dejar que una herramienta lo tocara. Esta es la misma lección que sigo reaprendiendo: leer una especificación no enseña casi nada comparado con convertir una carpeta mal.
Pasada uno: la columna vertebral, a mano. Tomé mi única carpeta más desordenada — trabajo con clientes — y la reconstruí manualmente. Creé el index.md, luego fui archivo por archivo decidiendo el type y escribiendo una description de una línea para cada uno. Esto fue lento, y la lentitud era el punto. Decidir si mi documento de precios era un pricing, un policy o un reference me obligó a entender realmente qué era cada nota. La mitad de mis archivos "duplicados" resultaron ser el mismo concepto escrito dos veces desde diferentes ángulos. La conversión sacó a la superficie la duplicación ante la que había estado ciego.
Mi mayor aprendizaje de la pasada uno: escribe tu vocabulario de type como su propio archivo de concepto antes de convertir cualquier cosa. OKF deliberadamente no dicta tus tipos, y esa libertad se convierte rápido en fatiga de decisión e inconsistencia. Creé business/type-vocabulary.md listando los ocho tipos que permitiría — playbook, runbook, reference, pricing, case-study, glossary, decision, index — y me negué a inventar un noveno sobre la marcha. Los tipos consistentes son la diferencia entre un bundle por el que un agente navega bien y uno por el que tropieza.
Pasada dos: automatización para el grueso. Convertir trescientos archivos a mano nunca fue el plan. Para el resto, me apoyé en el plugin okf-skills de Claude Code — un conjunto open-source de skills que enseña a Claude Code a crear, mantener y validar bundles OKF, impulsado por la especificación literal y respaldado por un verificador de conformidad. Esa última parte importa más de lo que suena: significa que la salida del agente se verifica contra la especificación en lugar de confiar ciegamente. También miré el OKF Bundle Generator de Suganthan Mohanadasan para la ruta URL-a-bundle, pero para una carpeta markdown local la ruta del skill de Claude Code encajaba mejor.
Aquí está la parte honesta: la automatización clavó el 80% fácil y falló en el 20% valioso. Página-a-markdown-con-front-matter es un problema resuelto — el skill agregó campos type y description a mis notas existentes limpiamente y marcó violaciones de la especificación. Lo que no pudo hacer de forma confiable fue el acto difícil: leer una nota de 2.000 palabras que secretamente contenía tres conceptos distintos y dividirla en tres archivos. Esa descomposición — Suganthan la llama "deshornear semántico" — es la parte que aún depende mayormente de ti. Un LLM puede intentarlo, pero apuntado a "divide esto en conceptos" ingenuamente produce archivos superpuestos y contradictorios. Revisé cada división a mano.
La única línea que lo cambió todo. Nada de la estructura importa si el agente no la usa. El desbloqueo fue una instrucción pequeña y explícita al inicio de Claude.md:
## Knowledge Base Protocol
Este es un bundle OKF. Antes de responder cualquier pregunta o crear cualquier archivo:
1. Lee `index.md` en el nivel relevante PRIMERO.
2. Usa los campos `description` de archivos para decidir qué abrir — NO abras
archivos para verificar relevancia.
3. Antes de crear un concepto, verifica el índice buscando uno existente.
Actualízalo en lugar de duplicar.
4. Después de cualquier cambio, agrega una línea a `log.md`.
Eso es todo. Cuatro reglas. El formato le da al agente un mapa confiable; esto le dice que realmente lea el mapa primero. Sin estas instrucciones, Claude trataba el bundle OKF como cualquier otra carpeta y volvía a buscar con grep. Con ellas, su comportamiento cambió visiblemente — lo cual es toda la historia de resultados.
Si prefieres que esta conversión se haga por ti — el vocabulario de tipos diseñado, la descomposición hecha correctamente, el protocolo Claude.md ajustado — eso es exactamente el tipo de pipeline que construyo. Puedes ver el trabajo en fiverr.com/s/EgxYmWD. Pero genuinamente: convierte una carpeta a mano primero. Tomará una tarde y te enseñará lo que ninguna herramienta hará.
Qué Se Rompió Durante la Conversión
Un registro de construcción sin los fallos es marketing, no enseñanza. Tres cosas me mordieron.
Los campos description eran perezosos, y el agente heredó mi pereza. Mi primer lote de descripciones eran cosas como "notas sobre precios" — inútil. Cuando toda la estrategia de navegación depende de que el agente lea descripciones en lugar de archivos, una descripción vaga rompe silenciosamente el sistema. El agente no puede distinguir pricing-logic de pricing-history si ambos dicen "notas sobre precios", así que abre ambos, y estás de vuelta al impuesto de tokens del que intentabas escapar. Tuve que reescribir cada descripción para que fuera discriminante — qué hace este archivo diferente de sus vecinos — no solo descriptiva. Esa reescritura tomó más tiempo que la conversión estructural.
Enlaces obsoletos por todas partes. Cuando divides y renombras archivos, las referencias internas se pudren. Mis notas antiguas hacían referencia cruzada por nombre de archivo, y la mitad de esos nombres cambiaron. OKF tolera enlaces rotos por diseño — la especificación trata los enlaces como aristas sin tipo y se encoge de hombros ante los muertos — lo cual es indulgente pero también significa que nada te advierte. Tuve que buscar manualmente referencias huérfanas con grep. Un verificador de enlaces va a mi lista de algún-día.
Al principio atomicé demasiado. Embriagado con la regla de "un concepto por archivo", fragmenté un manual de onboarding coherente en once micro-archivos: uno por paso. Eso no es minimalismo, es confeti. El agente ahora tenía que reensamblar un proceso único de once fragmentos, lo cual es peor que un archivo bien estructurado. Minimalismo en OKF significa una idea coherente por archivo, no una oración por archivo. Los recombié en un solo onboarding-sequence.md con secciones con encabezados. La línea entre "atómico" y "triturado" es juicio, y me equivoqué antes de acertar.
Ninguno de estos son dealbreakers. Es la fricción normal de imponer estructura sobre un año de desorden orgánico. Pero si entras esperando que una herramienta los maneje, enviarás un bundle que se ve conforme y navega mal. La especificación valida forma, no calidad. La calidad sigue siendo tu trabajo.
Cubierto eso, aquí está lo que realmente obtuve por el fin de semana.
Los Resultados del OKF Second Brain: Qué Cambió Realmente
Quiero ser cuidadoso aquí, porque esto es exactamente donde el contenido de bases de conocimiento se vuelve deshonesto con benchmarks inventados. No ejecuté un estudio controlado de conteo de tokens con barras de error limpias, así que no voy a darte un falso número de "73% menos tokens." Lo que puedo darte es qué cambió en el comportamiento observable del agente, y el mecanismo que lo explica.
La duplicación se detuvo. Esta era toda la razón por la que empecé. Porque la regla 3 del protocolo fuerza una verificación del índice antes de la creación, y porque el índice es un mapa real que el agente puede escanear económicamente, Claude ahora encuentra el concepto existente y lo actualiza en lugar de escribir cosa-v2-FINAL.md. En las semanas desde la conversión, no he atrapado un solo concepto duplicado. Eso solo justificó el fin de semana.
El agente abre menos archivos para responder. Antes, responder una pregunta significaba que el agente revisara varios archivos para encontrar el relevante. Ahora lee index.md, elige el archivo cuya description coincide, y abre ese. Lo vi responder una pregunta que solo uno de cuarenta conceptos podía abordar — leyó el índice, abrió exactamente ese archivo, y nunca tocó los otros treinta y nueve. El mecanismo es simple y real: parsear una descripción YAML corta es mucho más barato que leer el cuerpo completo de un archivo, así que filtrar por descripciones primero significa menos lecturas desperdiciadas de archivos completos. Eso no es un benchmark; es cómo funciona la revelación progresiva.
Dejó de re-derivar contexto. El cambio más satisfactorio es el más difícil de capturar en pantalla. Con una base de conocimiento estable y navegable, el agente deja de re-resumir el mismo contexto cada sesión porque puede encontrar confiablemente la versión sintetizada que escribió la última vez. La separación /raw vs wiki refuerza esto — el pensamiento terminado vive en la wiki y se reutiliza, en lugar de re-extraerse de notas crudas cada vez.
Es finalmente portable. Mi second brain ahora es una carpeta de markdown estándar que podría pushear a un repositorio Git, entregar a otro agente, o compartir una porción, y todavía significaría algo para la configuración de un extraño. Eso no era cierto antes. El formato es el lenguaje compartido que hace legible un sistema privado para cualquiera — humano o agente.
Para el argumento más profundo de "por qué la estructura estandarizada supera a un Claude.md inteligente," desglosé los niveles de memoria del agente en mis seis niveles de sistemas de memoria de Claude Code — OKF es esencialmente una implementación limpia y compartible de los niveles superiores.
El resumen honesto: OKF no hizo a mi agente más inteligente. Hizo legible el entorno de mi agente, y un entorno legible es lo que evita que un agente capaz actúe tontamente.
¿Deberías Convertir Tu Second Brain a OKF?
Respuesta directa: convierte si tu base de conocimiento es lo suficientemente grande como para que el agente pierda la pista de lo que hay dentro — y omítelo si tienes menos de cincuenta archivos y todo aún cabe cómodamente en la cabeza del agente.
La conversión tiene costo real. Pasarás horas escribiendo descripciones discriminantes, diseñando un vocabulario de tipos, y revisando divisiones automatizadas. Ese costo solo se paga cuando tu base es lo suficientemente grande como para que la navegación se haya convertido en el cuello de botella. Con treinta archivos bien nombrados, un buen Claude.md es genuinamente suficiente y OKF es excesivo. El impuesto de duplicación y búsqueda que experimenté es un problema de escala.
Convierte si alguno de estos es cierto: tu agente duplica conocimiento que ya tiene, la recuperación se siente lenta y pesada en tokens, quieres compartir o montar la base a través de herramientas, o ya estás ejecutando una wiki viviente estilo Karpathy y quieres que hable un estándar que otras herramientas puedan consumir. Si estás construyendo ese patrón de wiki viviente, mi Obsidian + Claude Code second brain walkthrough se complementa naturalmente con OKF — Obsidian para la vista de grafo humana, OKF como el estándar en disco debajo.
Espera si tienes menos de cincuenta archivos, si tu base es puramente personal y nunca se compartirá, o si estás tentado a convertir porque OKF es nuevo y brillante en lugar de porque chocaste contra un muro real. Nuevo no es una razón. Un muro sí.
Una cosa que no haría: tratar OKF v0.1 como terminado. Google lo llamó un punto de partida, y lo es — no hay protocolo de descubrimiento formal incorporado aún, ni validación de enlaces, ni aplicación de calidad. Construir sobre él es inteligente. Apostar toda tu operación en su forma actual no lo es. Convierte la parte que duele, aprende la forma, y deja que la especificación madure antes de ir all-in.
Preguntas Frecuentes
¿Qué es un OKF second brain?
Un OKF second brain es una base de conocimiento personal estructurada según el Open Knowledge Format de Google — un directorio de archivos de concepto markdown con front matter YAML, encabezado por un mapa index.md, que tanto tú como un agente de IA como Claude pueden leer, navegar y actualizar. Reemplaza carpetas ad-hoc y un largo Claude.md con una forma estandarizada y portable.
¿Cómo convierto una base de conocimiento Claude existente a OKF?
Convierte una carpeta a mano primero para aprender el formato, define un vocabulario de type fijo, luego usa una herramienta como el plugin okf-skills de Claude Code para agregar front matter al resto. El paso más difícil — dividir notas mezcladas en conceptos individuales limpios — aún necesita revisión humana. Termina agregando un protocolo de índice-primero a tu Claude.md. Consulta la guía de conversión arriba para los pasos exactos.
¿Hace OKF que Claude sea más rápido buscando en mis notas?
OKF reduce las lecturas de archivos desperdiciadas en lugar de hacer al modelo más rápido. Porque el agente lee campos cortos de description YAML en el índice antes de abrir cualquier archivo, filtra al concepto relevante sin revisar los irrelevantes — lo que reduce el uso de tokens en la recuperación. La ganancia escala con qué tan grande y desordenada era tu base al comenzar.
¿Aún necesito un archivo Claude.md con un OKF second brain?
Sí, pero su trabajo se reduce. En lugar de mantener toda tu estructura en prosa, Claude.md se convierte en un protocolo corto que le dice al agente que lea index.md primero, navegue por descripciones, verifique duplicados antes de crear, y registre cambios. La estructura vive en el bundle; Claude.md solo le dice al agente cómo usarlo.
¿Es OKF mejor que RAG para un second brain?
Resuelven diferentes problemas. RAG busca en una pila estática de fragmentos embedidos y reconstruye contexto en cada consulta sin acumular conocimiento. Un OKF second brain es un conjunto curado y vivo de conceptos que el agente lee y actualiza con el tiempo, así que se acumula. Para conocimiento personal en evolución que revisas, la estructura mantenible de OKF tiende a encajar mejor que RAG vectorial puro.
La Carpeta Que Dejó de Olvidar
Empecé todo este experimento por dos archivos de precios contradiciéndose. Lo termino ahí también, porque la resolución es el punto.
Unos días después de la conversión, le pedí a Claude que actualizara mi lógica de precios para un nuevo nivel de servicio. Leyó el índice raíz, fue directo a business/pricing-logic.md, abrió ese único archivo, lo revisó, y agregó una línea a log.md. Sin archivo nuevo. Sin v2-FINAL. Sin contradicción. Encontró lo que ya sabía y lo cambió, como lo haría una persona con memoria real.
Esa es toda la promesa de un OKF second brain, y es más pequeña y más honesta de lo que el hype alrededor del formato sugiere. OKF no le dio inteligencia a mi agente. Le dio un mapa en el que podía confiar — y un agente capaz con un mapa confiable deja de comportarse como un amnésico. El formato evolucionará más allá de v0.1, las herramientas mejorarán, y el mercado de bundles vendibles que la gente sigue prediciendo puede llegar o no. Nada de eso cambia el movimiento disponible para ti hoy.
Así que aquí está lo único que vale la pena hacer antes de que termine esta semana: toma tu única carpeta de conocimiento más desordenada — la que tu agente sigue tropezando — y convierte solo esa a OKF a mano. Escribe el índice. Escribe descripciones discriminantes. Agrega el protocolo de cuatro líneas a Claude.md. Luego hazle a tu agente una pregunta que solo un archivo puede responder, y mira qué hace. Si lee el mapa y abre exactamente el archivo correcto, entenderás en treinta segundos lo que me tomó un fin de semana sentir.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
