Guide

An Obsidian vault your AI can actually use.

Most people set this up by dumping every note and every chat log into Obsidian and pointing Claude at it. That is why they end up saying the whole thing is hype.

It is not about storing more. It is about storing less, in the right place. Three questions decide where everything goes, and the prompt at the bottom builds the whole thing for you.

Step 1

Decide where a fact goes before you save it.

Every fact lives in exactly one of three places, and never gets copied between them. Run each new thing down this list and stop at the first yes.

  1. Question 1

    Do you need this in every single session?

    Yes

    Always-on memory

    One fact per file, plus a one-line index. It costs context every session, so it has to earn its place.

  2. Question 2

    Does another system already own it and keep it current?

    Yes

    Store nothing

    Task board, CRM, calendar, repo, bank. Query it at the moment you need it instead of keeping a copy that goes stale.

  3. Question 3

    Is it durable, but too big to keep loaded?

    Yes

    The vault

    Raw material goes into sources/ untouched. Claude compiles it into wiki pages it writes for itself.

The rule underneath all three: if it changes on its own, do not write it down.

Step 2

Four folders and two files.

This is the whole vault. If something does not fit one of these, the answer is to change the rules on purpose, not to invent a seventh folder.

  • sources/

    Raw input, saved once and never edited. Articles, transcripts, meeting notes. Your source of truth.

  • wiki/

    Claude’s compiled pages, written by reading sources/. One concept per page, cross-linked.

  • workspace/

    Things actively being worked on. Not knowledge.

  • archive/

    Finished or superseded. Nothing in here is current.

  • index.md

    The map: what exists and where.

  • CLAUDE.md

    How to operate the vault. The rules, written as law for this folder.

Four folders and two files. The two in red are the whole engine: everything you collect lands in sources/, and Claude distils it into wiki/. A source is never rewritten, and the same wiki page never exists twice.

Step 3

Paste this once. It builds the rest.

You need Claude Code, which runs in a desktop app on Mac and Windows as well as in a terminal, so there is nothing to install beyond that. Open the folder you want the vault to live in, paste this, and answer the three questions it asks.

  1. 01

    You paste the prompt

    Into Claude Code, from a folder where you want the vault to live.

  2. 02

    It asks three questions

    What this should make it better at, which tools already hold live data, and whether you have existing notes.

  3. 03

    It writes the structure

    The folders, plus a CLAUDE.md whose routing table is built from your three answers, not from a template.

  4. 04

    It imports and compiles

    Only if you said you have notes. They go into sources/ untouched, then it reads them and writes the wiki pages itself.

vault-setup-prompt.md
You are setting up an Obsidian vault that you will read from and maintain for me
from now on. Read this entire brief before touching the filesystem.

# The architecture

Three tiers. Every fact lives in exactly ONE of them, never copied between them.

1. ALWAYS-ON MEMORY - facts you need in every single session, without me asking.
   One fact per file, plus a one-line index. Keep it small: it costs context every
   session, so it has to earn its place.

2. THE VAULT - durable knowledge that is too big or too detailed to keep loaded.
   Raw material goes in untouched; you compile it into your own wiki pages.

3. LIVE SYSTEMS - anything that changes on its own and is already owned by another
   system (task board, CRM, calendar, repo, bank). Store NOTHING. Query it when
   it is needed.

The rule that makes this work: if it changes on its own, do not write it down.

# Step 1 - ask me these three questions, one at a time, and wait for each answer

  1. What should this vault make you better at?
     (my work, a business I run, a subject I am studying, research)
  2. Which tools already hold live data for me?
     (Notion, Linear, a CRM, a calendar, GitHub, a bank)
  3. Do I have existing notes to bring in, or are we starting empty?

Do not continue until I have answered all three.

# Step 2 - build the structure

In the current directory create:

  sources/     raw input, saved once and NEVER edited afterwards. Articles,
               transcripts, papers, meeting notes. This is the source of truth.
  wiki/        your compiled pages. You write these by reading sources/.
               One concept per page. Cross-link them with [[wiki links]].
  workspace/   things actively being worked on. Not knowledge.
  archive/     finished or superseded. Nothing in here is current.
  index.md     the map: what exists and where. You keep it current.
  CLAUDE.md    the rules below, written out as law for this folder.

# Step 3 - write CLAUDE.md

Write CLAUDE.md in the vault root containing:

  - The three tiers above, and the one-fact-one-place rule.
  - A routing table: for each kind of thing I named in step 1, the exact folder
    it goes to. Be specific to my answers, not generic.
  - The four rules that stop a vault rotting:
      1. Keep originals in sources/ and distil from them. Never rewrite a source.
      2. One concept per page.
      3. Never store anything that changes on its own - link to the query instead.
      4. Anything unverified is labelled unverified, never stated as fact.
  - The frontmatter every wiki page carries:
      title, summary (one line), tags, created, updated, sources.
  - A closed list of allowed folders. If something fits nowhere, I add a row to
    the routing table first. You never invent a folder.

# Step 4 - import (only if I said I have existing notes)

Ask me where they are. Copy them into sources/ untouched - do not reorganise or
rewrite them. Then compile: read them and write wiki pages from them. Never paste
a source into the wiki. Distil it.

# Step 5 - write index.md

Every folder with one line on what belongs in it, plus links to the wiki pages
you created.

# Step 6 - show me

Print the resulting tree, then tell me in three sentences what to do the next
time I open this folder.

# While you work

  - Ask before overwriting anything that already exists.
  - Never invent a fact to fill a page. If a source does not say it, it does not
    go in.
  - Do not create empty placeholder pages.

The three answers are what make the result yours. They decide the routing table inside your CLAUDE.md, which is the file that stops the vault turning back into a folder of loose notes.

Step 4

Then give it something that tells you when it rots.

A vault does not break loudly. It drifts: a fact gets copied into two pages, a folder appears that was never agreed, a wiki page stops citing anything. This second prompt reads the rules Claude just wrote for your vault and builds a checker for those specific rules.

vault-linter-prompt.md
Read the CLAUDE.md in this vault. Then write me a linter that checks this vault
against the rules that are actually written in it - not against a generic idea of
what a vault should look like.

Build it as a single script I can run from the vault root.

# What it must check

Derive the checks from my CLAUDE.md, including at minimum:

  - Every folder that exists is on the allowed list in CLAUDE.md.
  - Every file sits in the folder the routing table sends it to.
  - Every wiki page has the exact frontmatter fields CLAUDE.md specifies.
  - Every wiki page cites at least one thing in sources/.
  - No [[wiki link]] points at a page that does not exist.
  - Nothing in sources/ has been modified since it was added.
  - No two pages state the same fact - report suspected duplicates rather than
    guessing which one is right.

# How it must behave

  - REPORT ONLY. It never edits, moves, renames or deletes a file. It prints what
    is wrong and where, and stops there. I decide what to fix.
  - Exit 0 when clean, non-zero when something failed, so I can wire it into a
    hook later.
  - Group the output by file, and print a one-line summary at the end.
  - Every finding names the rule in CLAUDE.md it came from, so I can tell a real
    violation from a rule I should change.

# After you build it

Run it once against the vault as it is now and show me the output. If it reports
a hundred findings, the rules are wrong, not the vault - tell me which rule is
too strict and what you would change it to.

Report only. Never auto-fix.

A linter that edits your notes will eventually delete something you wanted, and you will not notice for a month. This one prints what is wrong and stops. You decide every time, and half the findings will tell you the rule was wrong rather than the file.

That's it

What to expect once it is running.

The first week feels like extra work, because you are answering "where does this go" instead of dropping things in a pile. That question is the entire system, and after about a week you stop noticing you are asking it.

The payoff shows up when you ask Claude something and it answers from your own material instead of from the internet. It gets there because the vault told it what is durable, what is live, and what it should never have written down in the first place.

The tools I run alongside this are on the stack page.

You now run the same system I do.

The version I build inside companies is these same three questions pointed at their operations instead of their notes: what does the team need every time, what gets written down once, and what should never be stored because another system already owns it.

The last one of those saved a 50-editor agency over 200 hours a week.

If your team does something by hand every week that a system should own, that is the thing I would automate first.

Show me your process

15 minutes · No pitch · Free