11 — Obsidian Vault

A well-structured vault is shared memory between you and Claude. Session starts, context loads, work begins — no re-explaining who you are or what you're building.

Why a vault

Claude's context window is stateless. Every session, you start from zero unless you inject context explicitly. An Obsidian vault solves this: markdown files on disk, readable by any tool, structured to load exactly the right context at the right time.

The vault becomes the single source of truth for your business context, project status, and working memory.

Vault structure (PARA-style)

vault/
├── CLAUDE.md                    ← Claude's working memory (updated each /wrap-up)
├── 01-Areas/                    ← Ongoing responsibilities, never "done"
│   ├── _context/                ← Canonical business docs — load before any content work
│   │   ├── brand-voice.md
│   │   ├── icp.md
│   │   ├── positioning.md
│   │   └── products.md
│   ├── marketing-growth.md
│   ├── dev-infrastructure.md
│   └── content-writing.md
├── 02-Projects/                 ← Active work with a defined end state
│   ├── Claude Sessions/         ← Auto-saved session handoffs
│   ├── my-product/              ← index.md, BACKLOG.md, Handoffs/
│   └── client-project/          ← index.md, BACKLOG.md
├── 03-Resources/                ← Reference material, concepts, connections
├── 04-Archives/                 ← Completed or paused work
└── 05-Daily-Logs/               ← Daily knowledge log

Project folder template:

02-Projects/project-name/
├── index.md          ← overview, current status, wikilinks
├── BACKLOG.md        ← Kanban (To Do / In Progress / Done)
└── Handoffs/         ← per-session end notes

`_context/` — canonical business docs

This subfolder is the highest-value part of the vault. Load it before any content, copy, or positioning work. One source of truth — never duplicated.

File	Contents
`brand-voice.md`	Tone, personality, writing style, words to use and avoid
`icp.md`	Ideal customer — who you're building for, what they struggle with
`positioning.md`	Market position, differentiators, one-liners per product
`products.md`	Product summaries, stack, current status

When Claude reads these before writing copy, the output sounds like you. Without them, it sounds like everyone else.

`@`-imports in `CLAUDE.md`

The cleanest way to auto-load vault context at session start is to declare @-import paths at the top of your project's CLAUDE.md:

@~/vault/01-Areas/_context/brand-voice.md
@~/vault/01-Areas/_context/icp.md
@~/vault/02-Projects/my-product/index.md

Claude Code evaluates these on startup. The files are injected into context before the first message. No manual loading, no re-explaining.

Scope imports to the project. A marketing project pulls brand voice and ICP. A dev project pulls dev-infrastructure.md and the relevant index.md. Keep the context budget tight.

Session rituals

`/resume`

Reads CLAUDE.md + the latest session handoff + active project indexes. Returns precise current state — what's done, what's next, what to open. Start every session with this instead of re-explaining from scratch.

`/wrap-up`

Summarizes the session
Updates CLAUDE.md with current handoff state
Writes a handoff note into 02-Projects/Claude Sessions/
Links new files created during the session

These two commands make the vault a living document rather than a static reference.

Note conventions

Wikilinks: [[note-slug]] — filename without .md. Use for all internal cross-references.

YAML frontmatter: Required on every note.

---
title: Note Title
type: context | area | project | concept
status: active | paused | archived
updated: YYYY-MM-DD
tags: [tag1, tag2]
---

Consistent frontmatter makes pattern search reliable — you can filter by type: context or status: active without opening every file.

Tool routing

The vault is just markdown files on disk. You don't need the Obsidian MCP to read them — whatever context layer you run (a caching MCP, a direct file reader, or plain shell commands) reads the same files. The Obsidian MCP adds a round-trip through the server; direct file access is faster.

Route accordingly:

Task	Approach
Search vault by keyword	Pattern search on the vault directory
Read a specific note	Direct file read
Map vault structure	Directory tree (depth 2–3)
List area or project files	Tree on the target subdirectory

Keep the tool consistent. Mixing the Obsidian MCP with direct reads on the same files can produce stale results from the MCP's own cache.

Context loading order

When starting work on any project:

Check the project's CLAUDE.md for @path imports — if present, context is already loaded
If not, search the vault by project name to locate relevant notes
Load 01-Areas/_context/ canonical docs for content or positioning work
Read 02-Projects/[project]/index.md for current status

Never ask for information that may already be in the vault. Search first.

Knowledge capture (optional automation)

If you run session-end hooks, you can automate knowledge extraction into the vault:

Session ends
     │
     ▼
SessionEnd hook → extraction script
     │  Pulls concepts + connections from session transcript
     ▼
daily/YYYY-MM-DD.md  (raw daily log)
     │
     ▼  (compile step — runs nightly or on demand)
knowledge/concepts/  +  knowledge/connections/
     │
     ▼  (symlinks into vault)
03-Resources/Concepts/  ←→  Obsidian
03-Resources/Connections/ ←→ Obsidian
05-Daily-Logs/ ←→ Obsidian

Without automation, a manual /wrap-up achieves the same goal — just slower. The vault compounds in value either way. What matters is writing the handoff, not how it gets written.