Técnicas de construcción en Obsidian utilizadas solo por genios y personas de altos ingresos

Ganar dinero con IA no se trata de la "cantidad de notas"

Primero, hablemos con calma.

No hay ninguna investigación que sugiera una relación causal entre un ingreso anual de 100 millones de yenes y una configuración de Obsidian. No existen "plugins secretos conocidos solo por los ricos".

Lo que quiero decir con "jugador de 100 millones de yenes" no es alguien que almacena una cantidad masiva de conocimiento.

Se refiere a personas que pueden convertir la información que obtienen en:

• Toma de decisiones
• Negociación
• Contratación
• Juicio de inversión
• Diseño de producto
• Contenido
• Materiales de ventas
• Sistemas organizativos
• Activos intelectuales reutilizables

...a una velocidad extremadamente alta.

Los usuarios comunes de Obsidian piensan en "qué guardar".

Los usuarios fuertes piensan primero en "en qué situación, usando qué pregunta, recuperaré esta información en el futuro?"

Los usuarios aún más fuertes rastrean en qué decisión o resultado se convirtió ese conocimiento recuperado.

En otras palabras, lo que realmente deberías diseñar no es un "Segundo Cerebro".

Es un Sistema Operativo de Inteligencia Personal que acumula toma de decisiones y producción intelectual.

Obsidian guarda las notas como archivos Markdown locales. Un Vault es solo una carpeta, y los cambios realizados desde editores externos o scripts se reflejan en Obsidian. La configuración y la información de los plugins se separan en la carpeta .obsidian. Esto significa que Obsidian no es solo una aplicación, sino un "repositorio de conocimiento" que puede ser manejado por Git, CLI, Claude y Codex.

En este artículo, tratamos los elementos de Obsidian de la siguiente manera:

Una vez que alcanzas esta perspectiva, tu forma de usar Obsidian cambia por completo.

Capítulo 1: Investigando casos internacionales—La estrategia ganadora fue la "búsqueda", no la "organización"

1. Lo que se aprendió de los Vaults de 7 investigadores

Hay un estudio de caso publicado en 2025 que investiga el uso de Obsidian por parte de siete investigadores en ciencias de la computación de un instituto de investigación brasileño.

La conclusión más importante de este estudio no fue cómo los participantes creaban notas.

Fue el descubrimiento de que cómo pretendían recuperarlas en el futuro influía fuertemente en cómo creaban y organizaban las notas. Los participantes usaban barras de búsqueda, listas de etiquetas, etiquetas dentro del texto y enlaces internos para diferentes propósitos. Algunos usuarios también colocaban las notas creadas en una Bandeja de Entrada y las procesaban una vez a la semana.

Las propuestas de diseño derivadas por los investigadores se pueden resumir en estos tres puntos:

1. No exijas una clasificación perfecta desde el principio; prepara una estructura inicial mínima.
2. Permite que la estructura se modifique durante el uso.
3. Conecta el método de creación/organización con el método de búsqueda futuro desde el principio.

En otras palabras, no se trata de "crear las carpetas correctas".

Se trata de decidir cómo tu yo futuro buscará y registrar en consecuencia con esa ruta de búsqueda.

Este solo punto muestra que la mayoría de los cursos comunes de Obsidian están al revés.

Muchos cursos te hacen decidir primero las carpetas, etiquetas, plugins y apariencia.

Sin embargo, en realidad, la pregunta que debes decidir primero es esta:

Dentro de tres meses, ¿qué me estará preocupando cuando necesite esta información?

2. Nicole van der Hoeven—Haciendo de las notas un dispositivo de aprendizaje profesional

Nicole van der Hoeven, que trabaja como Developer Advocate e Ingeniera de Rendimiento, afirma que tomar notas continuas sobre el trabajo ha tenido un impacto positivo no solo en la velocidad de aprendizaje, sino también en su carrera en la industria tecnológica.

La clave no es que haya "creado una base de datos de conocimiento hermosa".

Es que registra el aprendizaje durante el trabajo y lo reutiliza para compartir públicamente, explicaciones y presentaciones.

Ella fluye las notas de aprendizaje más allá de los simples registros personales hacia:

• Presentaciones
• Artículos
• Videos
• Documentos
• Materiales educativos
• El próximo trabajo

Esta "conversión de entrada a salida" crea el valor económico del conocimiento.

3. Bruno Paz—Local, Markdown, plugins mínimos

El ingeniero de software Bruno Paz agrega todo, desde fragmentos de código, reuniones y especificaciones de proyectos hasta investigación y conocimiento de la vida, en Obsidian.

Sin embargo, más importante que poner todo en Obsidian es su filosofía de diseño.

Él enfatiza la portabilidad de Markdown y la gestión del historial mediante Git, adoptando una política de mantener el número de plugins al mínimo. Los plugins hacen que Obsidian sea conveniente, pero el contenido en sí mismo no debería depender demasiado de plugins específicos.

También estandariza Frontmatter como type con plantillas, coloca Wikilinks a notas relacionadas en topics, y los lista con Bases o Dataview.

La conclusión aquí es clara:

Poder recuperar con solo Markdown cuando algo se rompe es más importante que ser de alta funcionalidad.

4. Ian O’Byrne—Fluyendo la información de "Consumir → Curar → Crear"

Ian O’Byrne, que usa Obsidian en educación e investigación, estructura su Vault aproximadamente en este flujo:

• Consumir: Entradas como artículos, libros, documentos, podcasts
• Curar: Destilar puntos clave, relacionarlos, crear MOCs
• Crear: Salidas como blogs, boletines, materiales didácticos
• Meta: Información operativa para el propio Vault

Lo que importa no son los nombres de las carpetas.

Es la estructura donde la información se mueve desde la entrada, pasando por la creación de significado, hasta la salida. Él explica que el proceso es más importante que la plataforma y que el Vault evoluciona según sea necesario.

Resumiendo estos casos internacionales, los Vaults excelentes tienen cinco características en común:

1. Primero la recuperación—Trabaja hacia atrás desde las búsquedas futuras
2. Centrado en la salida—Fluye hacia entregables, no solo almacenamiento
3. Local primero—Usa Markdown como fuente de verdad
4. Esquema mínimo—No compliques demasiado los campos de entrada
5. Evolutivo—Cambia la estructura mientras la usas

Capítulo 2: Seis métricas que definen un "Vault de 100 millones de yenes"

El número de notas, número de enlaces y la belleza del Grafo no son métricas de rendimiento esenciales.

Yo mediría el rendimiento del Vault con estas seis métricas:

1. Latencia de Captura

El tiempo desde tener una idea hasta guardarla.

El objetivo es dentro de 30 segundos. Una estructura que te obliga a pensar en etiquetas, notas relacionadas y ubicaciones de guardado en el momento de la entrada es débil.

2. Tiempo de Recuperación

El tiempo que lleva alcanzar la información necesaria.

Apunta a dentro de 30 segundos para información general y dentro de 60 segundos para registros importantes de decisiones.

3. Costo de Reconstrucción de Contexto

El tiempo para restaurar de qué trataba una historia al mirar notas antiguas.

Una nota con solo un título de reunión es débil. Una nota que preserva "Antecedentes", "Decisión", "Razón", "Premisa" y "Próxima Acción" es fuerte.

4. Trazabilidad de Decisiones

El porcentaje de juicios importantes donde puedes rastrear posteriormente:

• Por qué se decidió
• Qué fue rechazado
• Qué premisas existían
• Qué condiciones activarían una reversión

5. Tasa de Conversión de Salida

El porcentaje de Notas Fuente o Notas Evergreen almacenadas que se reutilizaron para artículos, propuestas, productos, decisiones, reuniones o actividades de ventas.

6. Ejecutabilidad por Agentes

El porcentaje de veces que Claude o Codex pueden buscar, proponer y verificar sin malinterpretar las reglas del Vault.

Resumiendo, el ROI de un sistema de conocimiento se puede pensar de la siguiente manera:

ROI del Conocimiento = (Conocimiento Reutilizado + Decisiones Mejoradas + Fallos Evitados) / Tiempo dedicado a registrar, organizar y mantener

Incluso si el número de notas aumenta, si no se reutilizan, solo está creciendo el denominador.

Capítulo 3: Una estructura de Vault fácil para usuarios de habla hispana

Si estuviera construyendo desde cero, usaría esta estructura de nivel superior:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Entradas sin clasificar. No organices aquí. Las etiquetas generalmente son innecesarias. Este es un lugar "solo para guardar".

10_Daily

Registros de trabajo cronológicos. Deja notas, conversaciones, realizaciones y progreso que no merezcan crear notas independientes.

20_Projects

Actividades con una condición de finalización. "Aumentar las ventas" es un Área o Meta, pero "Revisar los precios del plan corporativo para septiembre de 2026" es un Proyecto. Los proyectos siempre deben tener un next_action.

30_Areas

Áreas de responsabilidad continuas. Gestión, ventas, contratación, finanzas, salud, familia, aprendizaje, etc. Las Áreas permanecen incluso después de que se completa un Proyecto.

40_Notes

Conocimiento para reutilización a largo plazo. Coloca aquí contenido que puedas explicar con tus propias palabras, no solo extractos. No es necesario seguir estrictamente "una nota, un concepto". En español, los sujetos y las premisas se omiten fácilmente, por lo que fragmentar en exceso rompe el contexto. El estándar es:

1 Nota = Contenido que quieras reutilizar como una unidad única en el futuro

50_Sources

Registros de información externa. Libros, documentos, artículos, videos, materiales de reuniones, datos de investigación, etc. Separa "lo que dijo la otra parte" de "cómo lo interpreté yo".

60_Entities

Entidades como personas, empresas, productos, clientes, competidores y tecnologías. Incluso si la misma persona o empresa aparece en múltiples proyectos, mantén solo una Nota de Entidad.

70_Outputs

Artículos, documentos de planificación, propuestas, guiones de video, presentaciones, materiales de ventas, especificaciones de producto, etc. Es crucial colocar las Salidas en una carpeta independiente de nivel superior. Un Vault destinado solo al almacenamiento se convierte en un cementerio de conocimiento.

90_System

Mecanismos que ejecutan el propio Vault, como plantillas, Esquemas, Bases, reglas de IA y Skills. Al construir esto, te vuelves capaz de explicar tus propias operaciones.

¿Debería ser un solo Vault?

En principio, sí. Los enlaces internos en Obsidian se resuelven dentro de un Vault; dividir los Vaults desconecta las relaciones entre el conocimiento. En el estudio mencionado, los participantes que dividieron su Vault en tres reportaron confusión en la búsqueda.

Sin embargo, separa físicamente lo siguiente:

• Información donde la entrada de IA externa está prohibida por contrato.
• Datos médicos, números de identificación personal, credenciales.
• Información de RRHH altamente sensible.
• Datos regulados.
• Información que no se puede pasar a modelos externos según la política de la organización.

Piénsalo como separar un "Vault Personal" y un "Vault Regulado".

Capítulo 4: No mezcles los roles de las carpetas, propiedades, enlaces y etiquetas

La razón más grande por la que los sistemas de Obsidian colapsan es expresar la misma clasificación usando carpetas, etiquetas, propiedades y enlaces a la vez. Fija sus roles de la siguiente manera:

Las carpetas son para el "Ciclo de vida"

Inbox, Project, Source, Output, Archive, etc. Representan en qué etapa del proceso se encuentra actualmente una nota.

Las propiedades son para "Tipos y Estados manejados por máquina"

type, status, created, project, revisit, etc. Las propiedades de Obsidian se guardan como YAML y pueden tener tipos como texto, lista, número, casilla de verificación, fecha, datetime y etiquetas.

Los enlaces son para "Relaciones semánticas"

[[Estrategia de Precios]], [[ABC Corp]], [[Reversibilidad de Decisiones]], etc. Convertir un tema en una nota en lugar de una etiqueta permite que ese tema en sí mismo contenga explicaciones, contraevidencia, materiales de referencia y MOCs.

Las etiquetas son para "Estados transversales temporales"

Limita las etiquetas a cosas como #review, #waiting, #question, #contradiction, #publish.

Conceptos como "Marketing" o "IA" deben ser enlaces siempre que sea posible. Usar etiquetas como diccionario conceptual conduce a la proliferación de etiquetas (por ejemplo, #IA, #InteligenciaArtificial, #IA_Generativa). En su lugar, usa Alias en las notas de concepto.

Capítulo 5: Esquema mínimo de propiedades

No intentes completar 20 elementos desde el principio. Divide el Esquema en tres etapas:

Etapa de Captura

Solo lo esencial:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Etapa Promovida

Agrega cuando adquiera valor para almacenamiento a largo plazo:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Estrategia de Precios]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Investigación de Precios de Competidores 2026-07]]"
confidence: medium
sensitivity: internal
``

Etapa Operativa

Agrega elementos necesarios para Proyectos o Decisiones:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Gestión]]"
due: 2026-09-30
next_action: Comparar planes anuales de 5 competidores
``

Capítulo 6: Reglas para nombres de archivo en español

No es necesario forzar el texto del cuerpo o los títulos en español a inglés. Sin embargo, mantén los nombres de las propiedades y los nombres de las carpetas utilizados para el procesamiento automático en ASCII. Yo uso estas convenciones de nomenclatura:

• Proyecto: PJT Rediseño de Precios Corporativos
• Decisión: DEC 2026-07-24 Hacer del Plan Anual la Propuesta Estándar
• Nota Evergreen: El Precio está Determinado por el Riesgo de Fracaso en la Implementación, No por el Número de Funciones

Haz que los títulos de las Notas Evergreen sean "Afirmaciones" en lugar de "Nombres de Categorías". Los títulos afirmativos te ayudan a recordar el contenido solo con los resultados de búsqueda.

Capítulo 7: Plantillas para incluir realmente

Nota Diaria

Incluye un "Registro de Fricción". Registrar "lo que busqué pero no pude encontrar" te permite mejorar el Vault basándote en fallos de búsqueda reales. Evoluciona la estructura a partir de las búsquedas fallidas, no de la preferencia estética.

Nota de Proyecto

Una Nota de Proyecto no es un almacén de tareas. Es el Centro de Comando del Proyecto donde cualquiera puede entender el estado actual en 30 segundos.

Nota de Decisión

En el trabajo de alto beneficio, la calidad de las decisiones es más importante que la información. Por lo tanto, las Notas de Decisión son el tipo de nota más valioso. El campo más importante es el Desencadenante de Reversión. Un excelente tomador de decisiones es alguien que puede escribir en el momento de la decisión bajo qué condiciones cambiaría de opinión.

Capítulo 8: Los MOCs son "Modelos de Pensamiento Editados", no listas de enlaces

Un buen MOC (Mapa de Contenido) contiene el juicio del editor. Es un modelo cognitivo editado que comprime cómo entiendes actualmente un campo completo, en lugar de solo una lista de notas relacionadas.

Capítulo 9: Creando un "Panel de Control de Gestión" con Bases

Obsidian Bases es una función central que te permite mostrar, filtrar y ordenar las Propiedades de las notas como una base de datos. Úsalo para crear una "Base de Proyectos Activos" o una "Base de Revisión de Decisiones" para recuperar juicios que han quedado pendientes.

Capítulo 10: Plugins por niveles

• Nivel 0 (Solo núcleo): Properties, Templates, Daily Notes, Bases, Search, Canvas, etc.
• Nivel 1 (Cuando surge fricción): QuickAdd, Templater, Tasks.
• Nivel 2 (Solo si Bases no es suficiente): Dataview.

Mantén los Community Plugins activos en 12 o menos. Registra el propósito, la alternativa y las condiciones de eliminación para cada uno.

Capítulo 11: El cambio decisivo en 2026—CLI oficial de Obsidian

A partir de julio de 2026, Obsidian tiene una CLI oficial. Te permite operar la versión de escritorio desde la terminal: buscar, leer, crear, actualizar propiedades y verificar tareas. Esto permite que Claude y Codex operen utilizando la propia lógica de resolución de Obsidian, en lugar de solo editar Markdown directamente.

Capítulo 12: La estructura correcta para un Vault nativo de IA

Dejar que la IA edite libremente todas las notas no es "utilización de IA". Eso es como entregar todos los documentos de la empresa a un pasante sin verificar. La división correcta del trabajo es:

• Humano: Objetivos, juicios de valor, aprobación final, edición de MOCs.
• Obsidian: Fuente de verdad, relaciones, historial, vistas.
• Claude: Destilar significado, comparación, contraargumentos, redacción.
• Codex: Cambios estructurales, scripts, validación, revisiones de diferencias.
• Git: Recuperación, auditoría, aislamiento de experimentos.
• Validador: Detección de violaciones de esquema y anomalías de enlaces.

Capítulo 13: Colocando CLAUDE.md y AGENTS.md

Claude Code lee CLAUDE.md como instrucciones continuas. Codex busca AGENTS.md. Coloca un "Contrato Operativo del Vault" en estos archivos para definir el idioma (prosa en español, propiedades en ASCII), reglas de seguridad (dry-run por defecto) y reglas de esquema.

Capítulo 14: Convirtiendo tareas de Obsidian en Skills a través de Claude

Define "Skills de Agente" para tareas que hagas más de tres veces o para calidad estandarizada. Por ejemplo, un skill obsidian-distill puede convertir notas de reuniones en bruto en Decisiones, Tareas y Notas Evergreen. Un buen Skill es un estándar de trabajo reejecutable con entradas, procedimientos, prohibiciones y condiciones de finalización explícitas.

Capítulo 17: Patrones de colaboración para Claude, Codex y CLI de Obsidian

• Patrón 1: Destilación de Notas de Reunión (Claude extrae decisiones/tareas).
• Patrón 2: Revisión de Gestión Semanal (Claude resume el progreso de la semana y los proyectos estancados).
• Patrón 3: Auditoría de Desviación de Esquema (Codex detecta inconsistencias en las propiedades).
• Patrón 4: Auditoría de Premisas de Decisiones (Claude verifica si los supuestos detrás de decisiones pasadas siguen siendo válidos).

Este es un uso que va más allá de "resumir notas con IA". Usas la IA como un controlador intelectual que audita tus juicios pasados.

Capítulo 18: Incluyendo un Validador de Vault

Si la IA está editando tu Vault, no te conformes solo con "parece que está bien". Implementa pruebas estáticas mínimas a través de scripts (por ejemplo, vault_check.py) para verificar tipos permitidos, estados y propiedades requeridas.