Obsidian Second Brain

Claude operates your Obsidian vault as a self-rewriting knowledge base. An evolution of Karpathy's LLM Wiki pattern: sources rewrite existing pages instead of just appending, contradictions reconcile automatically, and scheduled agents maintain the vault while you sleep. Everything worth remembering gets saved. Every update propagates everywhere it belongs.

---

Quick Start

0. Choose vault access method (in order of preference)

Try these methods in order. Use the first one available:

Method 0 - SessionStart hook (if configured): If hooks/load_vault_context.py is wired as a SessionStart hook in ~/.claude/settings.json, _CLAUDE.md is injected into context automatically at session start. Skip step 1 below. To wire it: bash scripts/setup.sh "/path/to/vault" or run /obsidian-setup.

Method A - Direct filesystem (default, always works): Use standard file tools (Read, Write, Edit, Glob) against the vault path. The vault is plain markdown, so every operation in this skill works this way with no setup. This is the normal path in Claude Code - the commands below use these tools directly.

Method B - MCP server (optional, mainly for non-Claude-Code clients): This repo ships its own MCP server at integrations/obsidian-mcp-server/ that exposes the vault as tools (obsidian_search, obsidian_read_note, obsidian_save_note, obsidian_capture, plus curator tools). It exists so other MCP clients - Hermes Agent, Claude Desktop, Cursor - can use the vault as a knowledge layer; in Claude Code itself, Method A is simpler and preferred. If those obsidian_* tools happen to be available in your client, you may use them instead of raw file tools. Setup lives in integrations/obsidian-mcp-server/README.md (it is uv run --no-project --with 'mcp<2' python .../server.py with OBSIDIAN_VAULT_PATH set, not an npx package).

1. First time in a vault → read _CLAUDE.md

Before doing anything in a vault, check if _CLAUDE.md exists at the vault root and read it:

Read <vault>/_CLAUDE.md

If it exists: follow its rules exactly - they override the defaults in this skill. Where _CLAUDE.md is silent, fall back to the defaults below. If it doesn't exist: use the defaults in this skill, then offer to create one.

If the SessionStart hook is active, _CLAUDE.md is already in context - skip this step.

2. First time with a new user → run discovery

Glob <vault>/**/*.md

Scan the structure to understand: folder names, template locations, naming conventions, frontmatter patterns. Then read 2-3 existing notes to calibrate writing style before creating anything new.

3. Bootstrap a new vault

If the user has no vault yet, run:

# One-line install + bootstrap (asks 3 questions: vault path, your name, preset)
curl -sL https://raw.githubusercontent.com/eugeniughelbur/obsidian-second-brain/main/scripts/quick-install.sh | bash

# Or manual:
python scripts/bootstrap_vault.py --path ~/path/to/vault --name "Your Name"

# With a preset:
python scripts/bootstrap_vault.py --path ~/my-vault --name "Your Name" --preset executive
python scripts/bootstrap_vault.py --path ~/my-vault --name "Your Name" --preset builder
python scripts/bootstrap_vault.py --path ~/my-vault --name "Your Name" --preset creator
python scripts/bootstrap_vault.py --path ~/my-vault --name "Your Name" --preset researcher

# With assistant mode (maintaining vault for someone else):
python scripts/bootstrap_vault.py --path ~/my-vault --name "Your Name" --mode assistant --subject "Boss Name"

Then just point the skill at the new vault path (Method A above). If you use the optional bundled MCP server, set OBSIDIAN_VAULT_PATH to the new path and restart the client.

Presets customize the vault for different use cases:

• executive - Decisions, people, meetings, strategic planning. Kanban: OKRs, Quarterly, Weekly.
• builder - Projects, dev logs, architecture decisions, debugging. Kanban: Backlog, Sprint, Done.
• creator - Content calendar, ideas pipeline, audience notes, publishing. Kanban: Ideas, Drafts, Published.
• researcher - Sources, literature notes, hypotheses, methodology. Kanban: Reading, Processing, Synthesized.

Default (no preset) gives a general-purpose vault. All presets use wiki-style by default.

Assistant mode creates a _CLAUDE.md configured for operating a vault on behalf of someone else. See references/claude-md-assistant-template.md.

See references/vault-schema.md for full structural details.

---

Core Operating Principles

AI-first vault rule (applies to every note)

The vault is designed for future agent to read and reason over, not for human review. Every note Claude writes - across all 46 commands - must follow references/ai-first-rules.md:

1. Self-contained context - each note explains itself; don't rely on backlinks alone
2. "For future agent" preamble - 2-3 sentence summary so any compatible agent can decide relevance in 10 seconds
3. Rich, consistent frontmatter - type, date, tags, ai-first: true, plus type-specific fields (see ai-first-rules.md for schemas per note type)
4. Recency markers per claim - "Mem0 raised $24M (as of 2026-04, mem0.ai)" so future agent knows what to verify
5. Sources preserved verbatim - every external claim has its source URL inline
6. Cross-links mandatory - every person/project/idea/decision uses [[wikilinks]]
7. Confidence levels - stated | high | medium | speculation where applicable

This rule lives in _CLAUDE.md Section 0 of every vault using this skill, and in references/ai-first-rules.md (the canonical specification with frontmatter schemas + preamble templates per note type). That path is relative to the install root, which is load-bearing: if it does not resolve from your working directory, search upward for it, and if you still cannot read it, say so before writing rather than producing a note that silently skips the rule. The seven requirements above are the floor and apply whether or not the spec is reachable.

Never create in isolation

Every write operation must ask: where else does this belong?

You create/update...	Also update...
A new project note	Kanban board (add to Backlog), today's daily note (link it)
A task completed	Kanban board (move to Done), project note (log it), daily note
A person note	Daily note (mention interaction), People index if it exists
A dev log	Daily note (link it), project note (Recent Activity)
A deal update	Side Biz / Deals kanban, Dashboard totals
A decision made	Project note (Key Decisions), daily note
A mention/shoutout	Mentions Log, person's note, daily note
A hook, contrarian angle, or content idea	social-media/ideas.md (if folder exists)
A specific reusable number or stat	social-media/data-points.md (if folder exists)
An external post that performed well + why	social-media/swipe-file.md (if folder exists)
Research findings worth keeping	social-media/research/YYYY-MM-DD - topic.md (if folder exists)
Any vault write	operation log (Logs/YYYY-MM-DD.md if Logs/ exists, else log.md), index.md (update if new note created)

Always propagate. Never create a single orphaned note.

Bi-temporal facts - never overwrite, always append

When a fact changes (role, company, status, location, tool), NEVER delete the old value. Add a new entry to the timeline: frontmatter array with both event time AND transaction time:

timeline:
  - fact: "CTO at Currentscale Labs"
    from: 2024-01-01            # event time: when it was true
    until: 2026-04-07
    learned: 2026-02-23         # transaction time: when the vault learned it
    source: "[[2026-02-23]]"    # where from
  - fact: "Architect at Currentscale Labs"
    from: 2026-04-07
    until: present
    learned: 2026-04-07
    source: "[[2026-04-07]]"

Top-level fields (role:, status:, company:) always reflect the CURRENT state. The timeline: preserves the full history with provenance.

This enables:

• Historical queries ("who was my manager in February?")
• Reflective thinking ("you believed X on Tuesday, then ingested Y on Wednesday and shifted to Z")
• Smart reconciliation (different facts at different times = not a contradiction)
• Full audit trail (when did the vault learn each fact, from what source?)

CRITICAL_FACTS.md - always loaded

A tiny file (~120 tokens) loaded alongside SOUL.md at L0 in every session. Contains facts needed in every conversation:

• Timezone
• Current manager
• Current location
• Current company and role
• Any other fact that's true RIGHT NOW and relevant to every interaction

Update this file whenever a critical fact changes. Keep it under 150 tokens.

Raw is immutable

In wiki-style vaults, the raw/ folder contains original sources (articles, transcripts, PDFs). Claude reads these but NEVER modifies them. They are the source of truth. If a wiki page gets corrupted, re-derive it from the raw source. When ingesting, always save the original to raw/ and the derived pages to wiki/.

Maintain index.md and log.md

Two structural files that keep the vault navigable and auditable:

• index.md - A catalog of all vault pages organized by category. Claude reads this FIRST when navigating the vault instead of searching - faster and cheaper on tokens. Update it whenever a new note is created or deleted. Format: - [[Note Name]] - brief description grouped under folder headings.

• log.md - An append-only chronological log of every vault operation. Every save, ingest, health check, and structural change gets a timestamped entry. Never delete or rewrite entries - only append. Format: ## [YYYY-MM-DD] action | Description

Per-day operation logs (modernized vaults)

Vaults initialized with /obsidian-init (v0.9+) use a split log structure instead of a monolithic log.md:

• Logs/YYYY-MM-DD.md - one file per day, append-only. Format: **HH:MM** - action | description
• log.md at vault root - pointer file only. Never write entries here; it explains the per-day structure and ships the entry template.

To migrate an existing monolithic log.md: run python scripts/migrate_log.py --vault <path>. To refresh the stats block in index.md after bulk writes: run python scripts/vault_stats.py --vault <path>.

When writing operation log entries, check whether the vault uses the old (log.md) or new (Logs/YYYY-MM-DD.md) structure and write to the correct location.

The vault is a living system

The vault is not a filing cabinet. It is a living knowledge base that rewrites itself with every input. When new information enters:

• Existing pages get REWRITTEN with new context, not just appended to
• Contradictions between old and new claims get resolved or explicitly documented
• New patterns across multiple sources trigger automatic synthesis pages
• Stale claims get replaced with current information, with history preserved

The vault after an ingest should be DIFFERENT - not just bigger. If pages that existed before aren't smarter, more connected, and more current, the ingest wasn't deep enough.

Two-Output Rule

Every interaction that produces insight must generate two outputs:

1. The answer - what the user sees in the conversation
2. A vault update - the insight filed back into the relevant note(s)

This applies to all thinking tools and any query where Claude synthesizes information from the vault.

Synthesis Hook

When Claude notices a pattern during any operation (ingest, query, challenge, emerge), it should automatically create a synthesis page in wiki/concepts/. Patterns include:

• The same concept appearing in 3+ unrelated sources
• A claim being reinforced by multiple independent sources
• A trend emerging across time-sequenced notes
• Two entities sharing unexpected connections

Synthesis pages are the vault thinking for itself - connecting dots the user hasn't connected yet.

Reconciliation

The vault should never contain two pages that disagree without knowing they disagree. When contradictions are found (during ingest, health checks, or queries), either:

• Resolve them: rewrite the outdated page, preserve history
• Document them: create an explicit conflict page marked as an open question

Use /obsidian-reconcile for vault-wide truth maintenance.

Proactive save reminders

Unsaved conversations are lost knowledge. Claude should proactively remind the user to save:

• After 10+ exchanges: suggest "Want me to run /obsidian-save before we continue?"
• When the user signals wrap-up (e.g., "ok", "thanks", "done", "bye", "that's it"): suggest "Before you go - want me to /obsidian-save this conversation?"
• When a logical work block completes (feature shipped, decision made, problem solved): suggest saving
• Never skip the reminder. This is especially critical on Claude Desktop where there's no background agent.

Search before creating

Before creating any new note, search for an existing one:

search(query="keyword from title")

Duplicate notes are vault rot. Merge or update instead of creating new.

Never claim absence from memory, never fabricate

Two failure modes corrupt the vault silently:

• False absence (most common): never say "no note exists" or create a note on the assumption none exists without searching exhaustively first - by every plausible name, alias, and folder, listing and grepping, not from memory. When in doubt, over-include and label the uncertainty.
• Fabrication: never invent facts, entities, rates, dates, or relationships that were not actually stated. Mark unknowns as TBD; an empty section is correct when nothing was said. External claims carry a source URL + recency marker; inferences carry a confidence level.

See the anti-fabrication and search-completeness hard rules in references/ai-first-rules.md.

Match the vault's voice

Read existing notes in the same folder before writing new ones. Match: frontmatter schema, heading style, list formatting, tone, emoji usage (or lack of it). Never introduce new conventions - extend what's already there.

Frontmatter is mandatory

Every note gets frontmatter. At minimum:

---
date: 2026-03-24
tags:
  - <note-type>
---

See references/vault-schema.md for full frontmatter specs by note type.

---

Write Rules

See references/write-rules.md for the complete guide. Summary:

• Links: Use [[Note Name]] for internal links. Always link to people, projects, and jobs mentioned in a note.
• Dates: ISO format (YYYY-MM-DD) in frontmatter. Human format (March 24) in body text.
• Naming: YYYY-MM-DD - Title.md for dated notes. Title.md for evergreen notes. No special characters except the ASCII hyphen -. Never an em dash (U+2014) or en dash (U+2013) in a filename: link matching compares stems literally, so 2026-07-26 - Title.md will not resolve a [[2026-07-26 - Title]] link, producing an orphan and a dangling link in the same write. The write-time validator checks file CONTENT, not filenames, so nothing catches this for you.
• Status values: active / planning / completed / archived / on-hold for projects. in-progress / done / waiting for tasks.
• Kanban: Items follow the format - [ ] 🔴 **Title** · @{YYYY-MM-DD}\n\tDescription [[Link]]

---

The _CLAUDE.md File

This is the most important concept in this skill.

_CLAUDE.md lives at the vault root and persists Claude's operating rules across every session and every surface (Claude Desktop, Claude Code, VS Code, terminal). Without it, Claude has to re-learn your vault conventions every conversation.

Precedence rule: _CLAUDE.md wins on all vault-specific rules (folder names, naming conventions, frontmatter fields, auto-save behavior, private folders). The defaults in this skill file apply only where _CLAUDE.md is silent. Never let skill defaults override an explicit _CLAUDE.md rule.

What it contains:

• Your vault's folder map and what each folder is for
• Frontmatter schemas for your specific note types
• Naming conventions you use
• What to auto-save vs. what to ask first
• People and projects that need special handling
• Links to key files (boards, dashboard, templates)

To generate a _CLAUDE.md for an existing vault, run vault discovery then use the template in references/claude-md-template.md.

To install it: write the file to the vault root. Every Claude session that starts in that vault should read it first.

---

Common Operations

Save info from conversation

When a conversation produces something vault-worthy:

1. Identify the note type (decision → project note, person met → People/, task → board + Tasks/, etc.)
2. Check if a relevant note already exists
3. Write or update - always frontmatter-first
4. Propagate to boards, daily note, linked notes

Create today's daily note

date = today in YYYY-MM-DD format
path = Daily/{date}.md

Read Templates/Daily Note.md, fill in the date fields, create the file. Then scan recent conversation for anything worth logging in today's sections.

Log a dev session

Read Templates/Dev Log.md. Fill: date, project name, what was worked on, problems solved, decisions made, next steps. Save to Dev Logs/YYYY-MM-DD - Project Name.md. Link from project note's Recent Activity section and today's daily note.

Update a kanban board

Boards use the kanban-plugin: board frontmatter. Columns are ## Column Name headers. Items are - [ ] **Title** · @{due-date}\n\tDescription [[Links]] Completed items move to the ## ✅ Done column with a strikethrough: - [x] ~~**Title**~~ ✅ Date

Run vault health check

uv run --directory "SKILL_ROOT" scripts/vault_health.py --path ~/path/to/vault

Reports: duplicate notes, orphaned files (no incoming links), stale tasks (overdue), empty folders, broken links, notes missing frontmatter.

Proactively suggest running this when the user says the vault feels messy, notes are hard to find, they mention duplicates, or they haven't mentioned a health check in a long time. Offer: "Want me to run a vault health check?"

---

Commands

These slash commands can be used in any Claude surface. Each one is smart - it reads context, searches before writing, and propagates everywhere changes belong.

Name matching: If a name argument has a typo or is approximate, search the vault for the closest match, show what was found, and confirm with the user before proceeding. Never silently create a note with a misspelled name.

Command selection: the longest matching trigger wins. Several triggers are prefixes of longer, more specific ones, so a shorter match is not evidence that the shorter command is the right one. Always check whether a longer trigger also matches before choosing.

The five collisions that exist today, with the correct routing:

The user says	Route to	Not to	Why it matters
"remind me every month...", "track a recurring..."	/obsidian-recurring	/obsidian-task	A one-shot card never recurs, which is the whole point of the request
"save this idea", "capture this"	/obsidian-capture	/obsidian-save	One small idea note, not a multi-subagent sweep across people, projects, tasks, decisions and boards
"save this person", "remember this person"	/obsidian-person	/obsidian-save	A person note, not a full conversation sweep
"synthesize what I know about X"	/vault-deep-synthesis	/obsidian-synthesize	One topic cross-referenced, not a whole-vault pattern scan
"find unnamed patterns"	/obsidian-emerge	/obsidian-synthesize	Surfaces patterns for the user, does not write synthesis pages unasked

When two commands still look equally plausible after applying the rule, ask which one rather than guessing - the blast radii differ enormously, and /obsidian-save in particular writes across many files.

---

/obsidian-save

The master save command. Reads the entire conversation and extracts everything worth preserving.

Steps:

1. Scan the conversation and identify all vault-worthy items: decisions, tasks, people mentioned, projects started, ideas, learnings, deals, mentions/shoutouts
2. Group items by type: people, projects, tasks, decisions, ideas, deals
3. Spawn parallel subagents - one per group - so all note types are handled simultaneously:
   • People agent: search for each person, create or update notes, log interactions
   • Projects agent: search for each project, create or update notes
   • Tasks agent: parse tasks, add to the right kanban columns
   • Decisions agent: find relevant project notes, append to Key Decisions sections
   • Ideas agent: search Ideas/ for related notes, create or append
4. After all agents complete: update today's daily note with links to everything saved
5. Report back: a clean list of what was saved and where

Do not ask for guidance on where to save things - infer it. Only ask if something is genuinely ambiguous (e.g. a person mentioned with no context on who they are).

---

/obsidian-daily

Creates or updates today's daily note. Full steps in commands/obsidian-daily.md (the source of truth).

In short: resolves the daily folder per references/folder-map.md, creates today's note from the daily-note template if missing, then fills it from three inputs - the current conversation (tasks, people, decisions), the calendar (today's events when available), and the boards (due/overdue kanban items) - plus a short overnight-changes line when scheduled agents ran. Existing notes are injected into, never overwritten. Returns the note path.

---

/obsidian-calendar <mode>

One calendar command with four modes. Claude Code only (needs the Google Calendar MCP). The first word selects the mode; a bare range word defaults to agenda; no argument at all defaults to agenda today.

• agenda [range] - reads the calendar and writes a re-derivable AI-first snapshot to wiki/agenda/ (type: agenda-snapshot). Range: today, tomorrow, week, next-week, a date, or a range. Cross-links attendees to [[Person]] notes; flags conflicts, 3+ back-to-back stretches, working-hours focus blocks, and externally-organized events. Read-only on the calendar; Google Calendar stays the source of truth.
• reconcile [window] - flags commitments the vault implies (project next_actions, due tasks, dated commitments in daily notes, fixed dates in CRITICAL_FACTS.md) that are NOT on the calendar, plus events with no vault context. Flag only - never adds or changes events.
• meeting [selector] - turns an event (last, next, today, event-id:<id>, or fuzzy title) into a type: meeting note in wiki/meetings/ with metadata pre-filled and empty Notes / Decisions / Action items sections (never fabricate meeting content). Cross-links attendees, backlinks any task whose calendar-event-id matches.
• schedule <args> - the only mode that writes to the calendar. Standalone ("<title>" <when> <duration>), from a task (task:<path>), or suggest-a-time (task:<...> suggest:<window>). Resolves attendee emails from person notes (never guesses), conflict-checks before writing, requests a Meet link when participants span domains, and writes calendar-event-id back into the task so a re-run reschedules rather than duplicating.

(Consolidated from the former /obsidian-agenda, /obsidian-reconcile-style calendar check, /obsidian-meeting, and /obsidian-schedule - same behaviors, one entry point. The natural-language triggers for all four still route here.)

---

/obsidian-recurring

Tracks a recurring obligation (payment, filing, ops) with a cadence and a computed next-due date.