Obsidian como second brain: cómo organicé mi caos de fullstack developer

5 min de lectura

El problema: información dispersa, contexto perdido

Trabajo como fullstack developer en una agencia. Eso significa múltiples proyectos en paralelo, reuniones con distintos equipos, decisiones técnicas que se toman en un call y se olvidan en el siguiente, y un backlog mental que crece más rápido de lo que puedo procesar.

Antes de armar este sistema, mi información vivía en al menos cinco lugares distintos: Notion para documentación del equipo, Apple Notes para ideas rápidas, Obsidian con una estructura caótica, conversaciones con Claude que se perdían entre sesiones, mensajes de Slack que no volvía a encontrar, y Google Docs compartidos que nadie actualizaba.

El resultado era predecible. Cada vez que necesitaba contexto sobre una decisión pasada, tenía que reconstruirlo desde cero. “¿Por qué elegimos esta arquitectura?” — no sé, preguntale a alguien que haya estado en ese call. “¿Qué quedó pendiente de la última reunión?” — dejame buscar en tres apps distintas.

El costo real no era el tiempo de buscar. Era la pérdida de confianza en mi propio sistema. Si no podía confiar en que la información estaba en algún lado, dejaba de documentar. Y si dejaba de documentar, la próxima búsqueda iba a ser todavía peor.

Por qué Obsidian (y no Notion, ni Apple Notes, ni nada cloud)

La decisión no fue obvia. Notion es lo que usa mi equipo. Apple Notes es lo más rápido para capturar algo. Pero ninguno resolvía el problema de fondo.

Notion es excelente para documentación colaborativa, pero como second brain personal tiene fricciones: depende de internet, la búsqueda es lenta en vaults grandes, no tiene un formato portátil (tus notas viven en su base de datos), y no podés operarlo fácilmente desde un agente de AI.

Apple Notes es perfecto para la captura rápida, pero no tiene metadata, ni links bidireccionales, ni queries, ni plugins. Es una caja donde las cosas entran y rara vez salen organizadas.

Obsidian ganó por tres razones:

  1. Archivos locales en Markdown. Mis notas son archivos .md en mi disco. Si Obsidian desaparece mañana, mi conocimiento sigue ahí. Sin lock-in, sin migraciones dolorosas.
  2. Extensibilidad. Plugins como Dataview, Templater, y Tasks convierten un editor de Markdown en un sistema de productividad programable. Y el ecosistema de la comunidad es enorme.
  3. Operabilidad por agentes. Con MCP servers, Claude Code puede leer, crear, y modificar notas de mi vault sin que yo tenga Obsidian abierto. Esto fue el diferenciador definitivo: mi second brain no es solo para mí, es también para mis agentes.

La arquitectura: PARA + Zettelkasten

Reorganicé todo el vault desde cero usando una combinación de dos metodologías:

PARA (Projects, Areas, Resources, Archive) de Tiago Forte para la estructura de carpetas. Te da un lugar claro para cada cosa según su nivel de accionabilidad.

Zettelkasten para el conocimiento permanente. La idea es que las notas atómicas, bien linkeadas entre sí, generan valor compuesto con el tiempo.

La estructura quedó así:

00-Inbox/ → Captura universal. Todo lo sin clasificar.
01-Projects/ → Proyectos activos con deadlines
endeavor/ → Proyecto principal (Next.js, Salesforce, AWS)
meetings/ → Notas de reuniones
prds/ → Product Requirement Documents
dailys/ → Daily standup logs
decisions/ → Architecture Decision Records (ADRs)
tickets/ → Tasks detallados como páginas
side-projects/ → Proyectos personales
02-Areas/ → Responsabilidades ongoing (feedbacks, career)
03-Resources/ → Material de referencia, investigación, prompts
04-Archive/ → Proyectos finalizados
05-Knowledge/ → Notas permanentes Zettelkasten
Calendar/ → Daily notes personales
Templates/ → Templates de Templater

La clave es que cada nota tiene frontmatter estandarizado:

---
type: meeting | daily | prd | adr | ticket | reference
project: endeavor | meli | nombre-proyecto
status: active | completed | archived
tags: [tag1, tag2]
created: 2026-04-17
---

Esto hace que todo sea queryeable. Dataview puede preguntarle al vault “¿cuáles son los meetings de Endeavor de esta semana?” o “¿qué PRDs están en draft?” y obtener respuestas en tiempo real.

El flujo diario

Mi día de trabajo tiene un ritmo predecible gracias a este sistema:

Mañana: arrancar con contexto

Abro la terminal, corro claude, y escribo /today. Claude Code crea mi daily note con las tareas pendientes de ayer, los meetings del día, y contexto relevante de lo que estuve trabajando. En 10 segundos tengo el panorama completo sin abrir ninguna app.

Durante el día: capturar sin fricción

Cuando algo aparece — una idea, un pendiente, un dato de una conversación — uso /capture desde Claude Code. La nota va directo al 00-Inbox/ con un título y metadata básica. No necesito decidir dónde va. Solo capturar.

Si tengo una reunión, /meeting crea la nota con el template correcto, en la carpeta correcta, con el contexto del último meeting del mismo proyecto. Yo solo lleno los puntos durante la call.

Fin del día: procesar el inbox

Cuando tengo un hueco, corro /inbox. Claude me muestra cada nota del inbox, sugiere a qué carpeta moverla basándose en el contenido y el frontmatter, y espera mi confirmación. En 5 minutos el inbox está vacío y todo está clasificado.

Viernes: wrap-up semanal

/wrapup genera un resumen cruzando toda la actividad de la semana: meetings, tasks completados, decisiones tomadas, notas creadas. Lo reviso, lo ajusto si hace falta, y con /notion-sync lo publico en Notion para que el equipo tenga visibilidad.

Automatización con Claude Code

La automatización es lo que separa un vault organizado de un second brain que realmente funciona. Sin ella, la fricción de mantener el sistema actualizado termina ganándole a la disciplina.

Slash commands: la interfaz de mi vault

Tengo 9 slash commands en .claude/commands/ que cubren todas las operaciones comunes:

CommandQué hace
/todayCrea daily note con contexto y tareas pendientes
/meetingCrea nota de reunión con historial del proyecto
/captureCaptura rápida al inbox
/inboxProcesa y clasifica notas pendientes
/statusGenera overview actualizado de un proyecto
/wrapupResumen semanal cruzando actividad del vault
/decisionCrea un Architecture Decision Record
/ticketCrea un ticket (tarea como página completa)
/notion-syncSincroniza nota o resumen a Notion

Cada command sabe dónde guardar las cosas, qué template usar, qué frontmatter aplicar, y qué contexto del vault incluir. Yo no tengo que recordar ninguna convención — el sistema las aplica por mí.

El skill global: vault-save

Además de los commands locales, tengo un skill global (/vault-save) en ~/.claude/commands/ que está disponible desde cualquier proyecto donde corra Claude Code. Si estoy trabajando en el repo del blog y quiero guardar un PRD en mi vault, no necesito cambiar de directorio. El skill sabe los paths exactos y las reglas de frontmatter para cada tipo de contenido, y usa MCP para escribir directamente en el vault.

MCP servers: el puente entre Claude y Obsidian

La pieza que conecta todo es un MCP server de Obsidian configurado como servidor global en Claude Code. Esto le da a Claude 14 herramientas para operar el vault: leer notas, buscar contenido, crear archivos, actualizar frontmatter. Sin tener Obsidian abierto, sin tocar el filesystem manualmente.

Combinado con los MCP servers de Notion y GitHub, el resultado es un agente que puede leer mi vault, crear un resumen, publicarlo en Notion, y actualizar un issue en GitHub. Todo desde un solo prompt.

Tickets: el sistema de tareas que escala

Para tareas simples uso checkboxes inline (- [ ] tarea 📅 fecha). Pero cuando una tarea necesita contexto, acceptance criteria, o seguimiento de status, la escalo a un ticket: una nota completa en 01-Projects/{proyecto}/tickets/ con su propio frontmatter y status flow (open → in-progress → review → done).

El Dashboard de Obsidian muestra tres vistas de tickets: abiertos por prioridad, en progreso, y completados en los últimos 14 días. La regla es simple: si se describe en una línea, es un checkbox. Si necesita más de una línea, es un ticket.

Qué cambió en mi trabajo

Después de varias semanas usando este sistema, los cambios más notables son:

Dejé de perder contexto entre proyectos. Cuando vuelvo a un proyecto después de una semana, /status me da el panorama en segundos. No necesito reconstruir nada de memoria.

Las reuniones se convirtieron en datos. Cada meeting tiene una nota estructurada con decisiones y action items que aparecen automáticamente en el Dashboard. Cuando alguien pregunta “¿qué decidimos sobre X?”, la respuesta está a un /search de distancia.

La documentación se escribe sola. No es que yo sea más disciplinado. Es que la fricción de documentar bajó tanto que el costo de NO hacerlo se volvió mayor. Crear un ADR toma 30 segundos con /decision. Documentar un meeting toma lo que dura la reunión. Capturar una idea toma un /capture.

El vault acumula inteligencia. Cuantas más notas tiene, mejor puede Claude responder preguntas sobre mi trabajo. “¿Cuándo fue la última vez que hablamos de CDC?” ya no es una pregunta retórica — es una query que tiene respuesta.

Mi backlog mental se vació. Todo lo que antes vivía en mi cabeza — pendientes, ideas, decisiones — ahora está externalizado en un sistema en el que confío. Y esa confianza es el cambio más importante de todos.

Próximos pasos

El sistema está estable y funcional, pero hay extensiones que quiero explorar:

  • Integración con Slack y Gmail para capturar automáticamente tareas y contexto que hoy se pierden en esos canales.
  • Telegram sync para captura mobile — poder mandarle un mensaje al vault desde el celular.
  • Obsidian Copilot para RAG sobre el vault: búsqueda semántica en lugar de keyword matching.
  • Cron jobs automatizados en la Mac para procesamiento del inbox y generación de reportes sin intervención manual.
  • Weekly reports auto-synced a Notion para que el equipo tenga visibilidad sin que yo tenga que publicar manualmente.

El vault es un organismo vivo. No está terminado y probablemente nunca lo esté. Pero la diferencia entre un sistema que evoluciona y un caos que se acumula es la estructura inicial y las automatizaciones que la sostienen. Y eso, al menos, ya lo tengo resuelto.


Si querés armar algo similar, mi recomendación es empezar por la estructura de carpetas y el frontmatter estandarizado. Los plugins y las automatizaciones pueden venir después. Lo que no puede esperar es decidir dónde va cada cosa — porque si no tomás esa decisión al principio, la vas a tomar (mal) cien veces por día.