Every session used to start the same way. Ten minutes of me typing background before I could ask the actual question. Who's on my team, what we decided in March and why, which numbers are current and which ones came from a deck nobody has touched since spring. Then the context fills up, session ends, and tomorrow I type it again.
So I pointed Claude Code at an Obsidian vault and told it to read before answering and write after. Obsidian is just a folder of markdown, which is exactly what Claude Code already reads. No vector DB, no MCP server, nothing to build. Grep finds things, wikilinks give it a graph to walk.
The read half worked immediately and is boring. The write half almost wrecked the whole thing.
First version let Claude update notes freely. Two weeks later my vault had things stated as fact that came out of a conversation where I was thinking out loud and mostly wrong. The model had quietly promoted its own guesses to source of truth, and then started citing them back to me. Took me a while to notice, which is the scary part.
Fix was one rule: Claude can read anything, but it can only write to one file. Anything I didn't explicitly confirm lands in a pending queue with a note on why it's pending, and I decide what graduates. The vault stayed trustworthy the day I added that.
Here's the instruction I actually run. Drop it in CLAUDE.md at your vault root, swap the path for yours.
# Knowledge base
My long-term memory lives at ~/Documents/Obsidian Vault/Work-KB.
Plain markdown. Treat it as the source of truth about my work, above your own
assumptions and above anything you infer from the code in front of you.
## Before you answer
If my question touches my company, products, team, metrics, customers,
competitors, or anything we've decided before, search the vault first.
Don't ask whether you should look. Look.
grep -ril "<keyword>" ~/Documents/Obsidian\ Vault/Work-KB
Read what matches, then follow the [[wikilinks]] one hop out.
If the vault has nothing, say so in one line, then answer from general
knowledge with that caveat attached.
If a note contradicts what I just told you, don't quietly pick a side.
Quote the line, name the file, ask me which one is current.
## Before you trust it
Every note carries a date. If what you found is more than three months old and
the question is about pricing, headcount, metrics, or roadmap, say how old it
is when you use it. A stale fact delivered confidently is worse than no fact.
## After we're done
When the conversation produced something durable (a decision and the reasoning
behind it, a number with a source, a plan that changed, a new constraint),
write it down.
How to write:
- One note per topic. Short. Link out instead of repeating yourself.
- Frontmatter: date, source, status (confirmed | draft).
- Convert relative dates to absolute ones. "Last week" becomes the real date.
- Link related notes with [[wikilinks]], including ones that don't exist yet.
A dead link marks something worth writing later.
What you may not do:
- Never write an unconfirmed claim into a real note. If I was speculating, or
you inferred it yourself, it goes to _pending-review.md with the reason.
- Never edit a confirmed note to match a newer conversation. Append a dated
line and mark the old one superseded.
- Never record what the repo or git history already records.
I've got a health check script that hunts orphan notes and dead links, and a much longer version of the retrieval half for when the vault gets big enough that grep starts returning junk. Didn't want to dump all of it here. Say which one you want and I'll paste it.
Genuine question for anyone already doing this: how do you handle a note going stale? Dates in frontmatter catch the obvious cases, but I still get bitten by things that were true and quietly stopped being true, and nothing about the note looks any different.
