The graveyard vault problem

You built it carefully. You watched the YouTube videos. You read the Building a Second Brain book, went through the Zettelkasten rabbit hole, maybe even paid for a Linking Your Thinking workshop. You set up the folders. You chose a color scheme for your tags. You captured everything for two weeks.

Then life happened. The vault filled up with half-processed notes and orphaned ideas. The weekly review never became a habit. The “second brain” never talked back.

This is the default outcome for most PKM systems. Not because the philosophy is wrong — but because passive storage systems require a discipline tax that most builders cannot consistently pay. The vault waits. You forget. The cycle repeats.

The problem is not your system design. The problem is that your vault has no execution layer.

This article is about fixing that. You will wire Claude Code directly into your Obsidian vault’s filesystem and configure it to run as a local AI execution engine — one that reads your notes, processes your inbox, transforms raw ideas into structured drafts, and generates weekly summaries. Not through a plugin. Not through a web app. Through the filesystem itself, with programmable behavior you define once and reuse indefinitely.

What this builds

By the end of this tutorial you will have:

  • A vault structure optimized for automated operation (not just visual organization)
  • A CLAUDE.md that defines how your AI operator behaves inside your knowledge system
  • Three production-ready skills: weekly-review, organize-inbox, and idea-to-content
  • An execution loop you can run daily in under 15 minutes

Who this is for: solo builders who are technically comfortable with a terminal, already use or want to use Obsidian, and want to go from “beautiful notes” to “operational system.”

Time to implement: ~2 hours for initial setup. ~15 minutes per daily operation afterward.

What you need:

  • Obsidian installed (free)
  • Claude Code (Claude Pro subscription, $20/month)
  • Basic terminal comfort — cd, ls, running commands

Why the filesystem beats every plugin

The Obsidian community has built hundreds of plugins. Dataview lets you query notes. Templater fills templates. Periodic Notes manages journals. These are genuinely useful tools — for passive organization.

But plugins operate inside the app layer. They can only do what the plugin author built them to do. If you want to reorganize 40 notes based on semantic relationships, extract themes across a month of captures, and write a structured brief from a two-sentence idea — you need something that operates at the filesystem level with actual reasoning.

Claude Code is a terminal agent that reads and writes files directly. When you launch it inside your vault directory, it reads your CLAUDE.md, understands the structure you have defined, and can execute complex multi-step workflows across your entire knowledge base. It does not require a GUI. It does not require an API integration. It runs where your files live.

This matters for three reasons:

Portability. Your vault is Markdown files on disk. The system works regardless of whether Obsidian releases a breaking update, changes pricing, or gets acquired. The execution layer is independent of the display layer.

Programmability. You define behaviors once in plain text files (skills), and they execute on demand. A solo builder who has invested 30 minutes defining a weekly review skill gets that behavior back every week at zero marginal cost.

Privacy. Your knowledge stays local. Notes go to the Claude API for processing, but nothing is stored in a third-party knowledge base, synced to a SaaS vault, or indexed by a platform you do not control.

System architecture

┌─────────────────────────────────────────────────┐
│                YOUR OBSIDIAN VAULT               │
│                                                  │
│  ┌─────────────┐     ┌──────────────────────┐   │
│  │  CLAUDE.md  │────▶│  Claude Code         │   │
│  │ (operator   │     │  (execution engine)  │   │
│  │  config)    │     └──────────┬───────────┘   │
│  └─────────────┘                │               │
│                    ┌────────────┼──────────┐    │
│                    │            │          │    │
│                    ▼            ▼          ▼    │
│  ┌─────────────┐ ┌──────────┐ ┌─────────────┐  │
│  │  Inbox/     │ │  Areas/  │ │  .claude/   │  │
│  │  (captures) │ │  (know.) │ │  skills/    │  │
│  └──────┬──────┘ └────┬─────┘ └──────┬──────┘  │
│         │             │              │          │
│         └──────────────┴──────────────┘         │
│                        │                        │
│                        ▼                        │
│        ┌───────────────────────────────┐        │
│        │           Output/             │        │
│        │  (drafts, reviews, reports)   │        │
│        └───────────────────────────────┘        │
└─────────────────────────────────────────────────┘

The execution flow has four stages:

  1. Capture — raw notes, links, fragments land in Inbox/
  2. Instruction — CLAUDE.md tells the agent what the vault contains and how to behave
  3. Processing — skills define repeatable workflows the agent executes on demand
  4. Output — structured content appears in Output/: drafts, summaries, roadmaps, specs

The critical insight: Claude does not “watch” the vault. It acts when you invoke it. This is intentional — you stay in control of when the system runs. The investment is in defining behaviors upfront so that each invocation does meaningful work rather than requiring you to re-explain the context every time.

Step 1: Build the vault structure for operation

Most Obsidian vaults are organized for visual browsing. An operational vault needs to be organized for programmatic navigation. The structure below is minimal and functional:

mkdir -p ~/vault-solo/{Inbox,Areas,Projects,Resources,Archives,Output,.claude/skills,.claude/agents}

If you already have a vault, replace ~/vault-solo with your vault path and add any folders that are missing.

What each folder does in execution context:

vault-solo/
├── Inbox/        ← raw captures, quick notes, anything unprocessed
├── Areas/        ← ongoing knowledge organized by domain
├── Projects/     ← active work with defined scope and deadline
├── Resources/    ← references, research, external material
├── Archives/     ← completed or inactive notes
├── Output/       ← everything Claude produces: drafts, reviews, logs
└── .claude/
    ├── CLAUDE.md ← operator configuration (the most important file)
    ├── skills/   ← reusable workflow definitions
    └── agents/   ← subagent configurations (for advanced use)

Verify the structure exists:

ls -la ~/vault-solo/

Step 2: Write the CLAUDE.md — your operator configuration

This is the highest-leverage file in the system. Everything else depends on it.

The CLAUDE.md is not a README. It is not documentation for humans. It is a behavioral contract for the AI operator — it tells Claude what your vault contains, how it is organized, what it is allowed to do autonomously, and what requires your approval.

A vague CLAUDE.md produces generic behavior. A precise one produces consistent, predictable execution you can rely on.

touch ~/vault-solo/.claude/CLAUDE.md

Here is a production-ready template. Customize the identity and rules to match your actual context:

# CLAUDE.md — Vault Operator Configuration

## Operator identity
You are the execution engine of this Obsidian vault. Your role is to read,
organize, transform, and produce — not to passively answer questions.

When invoked, you read this file first, understand the vault structure,
then execute the requested operation or skill.

## Vault structure
- Inbox/     → unprocessed captures, raw notes, quick ideas
- Areas/     → continuous knowledge organized by domain (code, finance, health, etc.)
- Projects/  → active projects, each in a subfolder with its own context
- Resources/ → external references, research, saved articles
- Archives/  → completed or inactive material
- Output/    → all files you produce (drafts, summaries, specs, reports)

## Behavioral rules
1. Always ask before moving or deleting files in Areas/ or Projects/
2. You may organize Inbox/ freely: rename, move, add frontmatter, categorize
3. File naming convention: YYYY-MM-DD-short-descriptive-title.md
4. Every note you create must have frontmatter: title, date, tags, status
5. When summarizing, preserve the author's voice — do not rewrite in AI prose
6. Maintain [[wikilinks]] when connecting notes makes semantic sense

## Available skills
Check .claude/skills/ for defined workflows. Execute them when requested.

## Frontmatter standard
---
title: "Note title"
date: YYYY-MM-DD
tags: []
status: draft | active | archived
---

Open Obsidian, navigate to .claude/CLAUDE.md, and verify the content renders correctly.

Step 3: Create the weekly-review skill

Skills are Markdown files stored in .claude/skills/. Each one defines a repeatable workflow the agent executes on demand. You write it once. You reuse it indefinitely.

mkdir -p ~/vault-solo/.claude/skills/weekly-review

cat > ~/vault-solo/.claude/skills/weekly-review/SKILL.md << 'EOF'
---
name: weekly-review
description: Automated weekly review of the entire vault
---

# Weekly Review

Runs a full automated review of the vault for the past 7 days.

## Steps
1. List all notes created or modified in the last 7 days across Inbox/, Areas/, Projects/
2. Flag notes with no tags or stuck in "draft" status for more than 3 days
3. Write a 1-2 sentence summary for each note processed
4. Identify possible wikilink connections between notes that are not yet linked
5. List all active projects in Projects/ and their last-modified date
6. Write the full review output to Output/weekly-review-YYYY-MM-DD.md
7. End with 3 recommended priority actions for the coming week

## Output structure
The review note must include:
- Notes processed this week (with summaries)
- Orphaned notes without clear category
- Active projects and update recency
- Suggested new connections
- Recommended actions for next week
EOF

Test it immediately. Navigate to the vault and invoke Claude:

cd ~/vault-solo && claude

> run the weekly review

Claude will follow the defined steps. The output appears in Output/.

Step 4: Create the organize-inbox skill

The inbox is where the graveyard starts. This skill turns inbox processing from a chore requiring discipline into a command you run when you have five minutes.

mkdir -p ~/vault-solo/.claude/skills/organize-inbox

cat > ~/vault-solo/.claude/skills/organize-inbox/SKILL.md << 'EOF'
---
name: organize-inbox
description: Processes and routes all notes in Inbox/ to their correct destination
---

# Organize Inbox

Processes every note in Inbox/ and prepares it for routing.

## Steps
1. List all files currently in Inbox/
2. For each file:
   a. Read the content
   b. Classify it: idea, reference, capture, task, or draft
   c. Determine best destination: Areas/, Projects/, Resources/, or Archives/
   d. Add or repair frontmatter if missing
   e. Add relevant tags based on content
3. Present the full organization plan to the user before taking any action
4. After approval, execute all moves and frontmatter updates
5. Write a processing log to Output/inbox-log-YYYY-MM-DD.md

## Rules
- Never move a file without presenting the plan first
- Never modify note body content — only frontmatter and file location
- Add "source: inbox" to frontmatter of every processed note
- If a note clearly belongs to an existing project in Projects/, flag it
EOF

Step 5: Create the idea-to-content skill

This is the economic engine of the system. A two-sentence idea in your inbox becomes a structured draft in 15 minutes. At scale, this is the difference between “I have a lot of ideas” and “I publish consistently.”

mkdir -p ~/vault-solo/.claude/skills/idea-to-content

cat > ~/vault-solo/.claude/skills/idea-to-content/SKILL.md << 'EOF'
---
name: idea-to-content
description: Transforms a raw idea note into a fully structured content draft
---

# Idea to Content

Converts a raw idea into a publication-ready draft.

## Inputs
- Path to the source note containing the idea
- Target format: article | thread | email | documentation | landing-page

## Steps
1. Read the source note
2. Extract: core insight, problem being solved, intended audience
3. Build content structure for the chosen format:
   - article: working title, hook, 3-5 H2 sections with purpose, conclusion angle
   - thread: opening hook, 6-8 sequential points, closing CTA
   - email: subject line, opening, value delivery, single CTA
   - documentation: overview, setup, usage, worked example
   - landing-page: headline, problem statement, solution frame, feature list, CTA
4. Write the full draft to Output/draft-YYYY-MM-DD-[topic].md
5. Add complete frontmatter to the draft
6. Add a wikilink back to the source note in the draft frontmatter

## Draft frontmatter
---
title: "Working title"
date: YYYY-MM-DD
format: article | thread | email | docs | landing
status: draft
source: [[original-idea-note]]
---
EOF

Step 6: Install Claude Code and run the system

If you have not installed Claude Code:

# Via npm
npm install -g @anthropic-ai/claude-code

# Via Homebrew (macOS)
brew install claude-code

Running the system is a single command:

cd ~/vault-solo
claude

Claude reads CLAUDE.md automatically on launch, understands your vault, and is ready for operation. You do not need to re-explain anything. The config does that work.

From here, you operate in plain English:

> run the weekly review
> organize the inbox
> transform Inbox/idea-saas-scheduling.md into an article
> show vault status: notes per folder, notes without tags, stale projects

Step 7: Configure Obsidian for compatibility

Open Obsidian and point it to ~/vault-solo as the vault directory.

Under Settings → Files & Links:

  • “Detect all file extensions” → ON (so Claude-generated files appear in Obsidian)
  • “Use [[Wikilinks]]” → ON (maintains link format the agent uses)

Community plugins that integrate well with this setup:

  • Dataview — surface Claude-generated summaries and project status in dashboards
  • Templater — create note templates Claude can populate when creating new files

Three execution scenarios

Scenario: The accumulated inbox

You have not touched your vault in two weeks. There are 28 notes in Inbox/. Some are links you saved. Some are voice transcriptions. Some are half-formed thoughts from a meeting.

cd ~/vault-solo && claude
> organize the inbox

Claude reads all 28 notes, classifies each one, and presents a routing plan: “14 go to Areas/code, 6 to Projects/client-x, 4 to Resources/design, 4 to Archives.” You review the plan, approve, and the inbox is empty in 5 minutes. Every note has clean frontmatter and is linked to its context.

Without this system, those 28 notes sit in inbox limbo until you have the energy to manually process them — which is usually never.

Scenario: Friday knowledge synthesis

It is end of week. You have been capturing ideas, notes, and references all week. You want to know what you actually produced, what needs attention, and what the priorities are for Monday.

> run the weekly review

In 5 minutes you have a structured document in Output/ that lists every note from the week, identifies orphans, surfaces stale projects, suggests connections you have not made yet, and recommends three specific actions. This is the weekly review that “Building a Second Brain” describes but that most people abandon after three weeks because it requires too much manual effort to be sustainable.

When it requires a single command, you run it every week.

Scenario: Idea to publishable draft

You have this note in your inbox:

What if you could run a Zettelkasten entirely from the terminal, 
with AI doing the linking automatically? 
Like a graph that builds itself.

> transform Inbox/idea-zettelkasten-terminal.md into an article

Claude extracts the core insight, identifies the angle (tools-for-thought meets automation), builds a five-section structure, and writes a complete draft — including a working title, intro that frames the problem, and a conclusion with a clear CTA. The draft is in Output/ with full frontmatter and a backlink to the source idea. You spend 30 minutes editing it into publishable shape.

The economics of this at scale: if you capture 10 ideas per week and 3 of them become publishable content, you are running a content operation that would otherwise require a team.

The execution loop

The value of this system compounds over time. Here is what the flywheel looks like after the first 30 days:

Week 1–2: You define the skills and spend most of your time iterating the CLAUDE.md. The behaviors are not tuned yet. This is normal.

Week 3–4: The vault has enough material that the weekly review starts surfacing real connections. The inbox skill is running on a predictable pattern. You start trusting the output.

Month 2+: The vault accumulates structured knowledge about your specific domain. Claude’s execution improves because the context in CLAUDE.md and the notes themselves has grown. A two-sentence idea now generates a draft that requires only light editing because the agent understands the topics you work in.

This is what Tiago Forte meant by a “second brain” — but the version that actually works requires an execution layer, not just a storage layer.

Revenue models

Content pipeline at scale

Every idea in your inbox becomes a draft. Consistent publishing generates organic traffic. If your blog monetizes through affiliates, display ads, or your own digital products, this pipeline directly feeds revenue.

Realistic output: 2-3 publishable drafts per week from 10-15 idea captures. In a focused niche with AdSense or affiliate monetization, 6-month compounding of consistent publishing can generate $500–2,000/month depending on niche competition.

Productized knowledge

The vault is not just content for a blog. Organized notes on a specific technical domain become an ebook. Validated workflows become sellable templates. Documented processes become a consulting offer.

The idea-to-content skill generates documentation outlines as well as articles. A well-organized vault on a specific subject — AI integration patterns for small businesses, for example — is a sellable information product. A focused ebook with solid SEO positioning can generate $1,000–5,000 in launch sales and long-tail revenue.

Multiplied service delivery

If you sell services, this system makes you faster without adding headcount. Client briefs, project documentation, research summaries — all processed through skills that run in minutes rather than hours.

The leverage is asymmetric: the time you invest defining skills is fixed and one-time. The time you recover per operation compounds indefinitely.

Limitations to know before you build

Claude Code requires connectivity. It is not a fully local system. File operations are local, but language processing runs on Anthropic’s API. For truly air-gapped operation you would need a local model like Ollama — but the reasoning quality for multi-step workflows is significantly lower.

Context limits apply at scale. If your vault contains 8,000+ notes, Claude cannot process all of them in a single operation. The solution is domain-specific invocation: run the weekly review against Projects/active rather than the entire vault. Design your skills with scope in mind.

The CLAUDE.md is your bottleneck. Generic instructions produce generic behavior. If a skill produces output that misses the mark, the fix is almost always in the CLAUDE.md, not the skill itself. Treat the CLAUDE.md as living configuration you refine over time.

No passive monitoring. Claude does not watch your vault for changes. It acts when invoked. If you want event-driven behavior (e.g., “process Inbox whenever a new note appears”), you would need to set up a cron job that invokes Claude on a schedule — which is doable but adds complexity.

Back up your vault. Git is the right tool:

cd ~/vault-solo
git init
git add .
git commit -m "initial vault"

Run git commit after every significant session. Your knowledge is your asset.

This is not PKM. This is operations.

The note-taking community has spent a decade debating the best way to organize information. Zettelkasten vs. PARA vs. Johnny Decimal. Cards vs. outlines. Folders vs. tags. Backlinks vs. hierarchy.

These debates are mostly about how to make passive storage more navigable.

What you are building here is different. The folder structure is not for browsing — it is a routing system for an AI operator. The CLAUDE.md is not documentation — it is a behavioral contract. The skills are not templates — they are reusable programs.

The insight that changes everything: your notes are only as valuable as the workflows that process them.

A vault with 5,000 perfectly-linked notes that you open once a week to browse is a library. A vault with 500 notes and three reliable skills that you invoke daily is an operating system.

Solo builders do not need better note-taking apps. They need execution infrastructure. This is what that looks like.

Frequently asked questions

Does this work on Windows?

Claude Code runs on Windows via WSL (Windows Subsystem for Linux) or PowerShell. The file operations are cross-platform. The terminal commands in this tutorial use Unix syntax — adapt paths and commands for your environment if running natively on Windows.

How is this different from using ChatGPT with file uploads?

ChatGPT file uploads are stateless — you upload, get output, and nothing persists. Claude Code operates on your actual filesystem: files it writes are real files in your vault that persist, link to other notes, and accumulate over time. The context from previous operations is also available because it lives in the vault itself.

Can I use this without Obsidian?

Yes. The system depends on your filesystem, not on Obsidian. Obsidian is the display layer. You could use VS Code, Typora, or any Markdown editor as the viewing interface. The CLAUDE.md and skills work the same regardless of how you view the notes.

Does the agent understand my existing notes on the first run?

It understands the structure you define in CLAUDE.md and can read individual note content when processing. It does not preload all your notes into memory. Operations that reference specific notes work well. Operations that require semantic awareness across thousands of notes need to be scoped to specific folders.

Will my notes be used to train Anthropic’s models?

By default, Claude API inputs are not used for training. Verify Anthropic’s current data usage policy at anthropic.com if this is a concern. You can also review Claude Code’s privacy settings with claude --help.

What happens if Anthropic changes Claude Code pricing?

The skills and CLAUDE.md are portable. If you need to switch to a different agent runtime, the configuration files are plain Markdown — you can adapt them to any tool that reads a project context file. The investment is in the structure and workflow definitions, not in a specific platform.

Where to go from here

The fastest path to value:

  1. Run the vault setup now — 15 minutes. Structure + CLAUDE.md.
  2. Create the weekly review skill — 10 minutes. Test it immediately, even with an empty vault.
  3. Capture 5 ideas in Inbox this week — do not overthink the notes. Raw is fine.
  4. Run your first weekly review on Friday — see the system produce real output.
  5. Refine the CLAUDE.md — iterate based on what the output missed or got wrong.

The first four steps take under 30 minutes. The fifth step is a practice you run forever.

What starts as a productivity system becomes, over six months, a knowledge operating system that understands your business better than any tool you could buy. You built it. It runs on your machine. You own it entirely.

That is the structural advantage of building over buying.