Three Claude Code skills that make an Obsidian vault the source of truth for how you work — so Claude follows your documented standards instead of generic defaults.
| Skill | What it does |
|---|---|
/brain |
Loads the standards, processes, and decisions that govern the task at hand, before the work starts |
/cr |
Reviews a pull request against those standards — inline comments on changed lines only, severity separated, ends with a verdict |
/learn |
Captures what was learned back into the vault as an atomic, linked note, plus a short pointer in session memory |
They form a loop. /brain reads the vault, /cr judges code against it, /learn
writes back to it. The vault gets better every cycle, and every skill gets better
with it.
The skills hold no knowledge of their own. They only know how to find your knowledge. Every rule lives in the vault and nowhere else.
That is deliberate. Copy a standard into a skill file and you now have two copies — they drift, and nobody knows which one is true. Update the vault and every skill's behavior changes on the next run, with no edits here.
claude plugin marketplace add zitdevs/vault-skills
claude plugin install zitdevs@zitdevsOr, from inside Claude Code:
/plugin marketplace add zitdevs/vault-skills
/plugin install zitdevs@zitdevs
Restart Claude Code afterwards — skills and commands are loaded at startup.
They default to ~/Documents/Obsidian. Anywhere else, set:
export OBSIDIAN_VAULT="/path/to/your/vault"/brain reads $OBSIDIAN_VAULT/CLAUDE.md first and treats it as
authoritative — above the skill files themselves. Without it, the vault has
no taxonomy and the skills are guessing.
Copy the starter and adapt it:
cp templates/vault-CLAUDE.md "$OBSIDIAN_VAULT/CLAUDE.md"The entity names in it are examples. Replace them with your own employers, clients, and projects.
The skills look for notes by frontmatter, not by path — so you can reorganize the vault freely. At minimum, write:
| Note | Tags | Loaded by |
|---|---|---|
| Engineering principles | area/core, topic/architecture |
/brain, /cr |
| Testing standards | area/core, topic/testing |
/brain, /cr |
| Code review process | area/core, topic/review |
/cr |
Each note needs frontmatter like:
---
type: process
created: 2026-01-15
tags: [area/core, topic/review]
---Entities layer addenda on top: a note tagged area/acmecorp, topic/review adds
that employer's rules to the core process. /cr loads both.
fd,ripgrep,bat—brew install fd ripgrep batgh, authenticated — required by/cr- A memory MCP such as Engram — optional;
/learnskips that step cleanly when none is connected
/brain # load the vault protocol and index
/brain code review # load the standards governing PR review
/brain architecture
/cr https://github.com/org/repo/pull/123
/cr 123 -R org/repo
/cr # the current branch's PR
/learn # capture what was just discussed
/learn <topic> # study it first, then capture
Each is also reachable as a namespaced skill — zitdevs:cr, zitdevs:brain,
zitdevs:learn — which is how Claude invokes them on its own, without you
typing anything.
Worth calling out, because it is the part most review tooling gets wrong:
- Ticket before diff. Without the intent, there is no standard to judge against.
- Inline comments land only on changed lines. GitHub's review API happily
accepts unchanged context lines inside a hunk — which is how bots end up
commenting on code the author never touched.
changed-lines.shcomputes the real commentable set, and it is checked as a gate, not remembered as a rule. - Severity is separated. Suggestions are the default and do not block; critical findings are stated as required in the review body. Framing everything as required makes the truly required invisible.
- CI colour is not a verdict. A red check gets diagnosed before it influences anything — infra flake gets approved anyway, a real test failure blocks. A bot reporting success because it hit a usage limit reviewed nothing, and the review says so.
- Every review ends with a decision. Approve, comment, or request changes. Comments alone leave the PR in limbo.
- Posting is confirmed first, every time — including approvals. A review is outward-facing and visible to the team.
These encode one particular way of working. Fork it, or better: change the vault, not the skills. Nearly everything that feels wrong for your team lives in a note, not in this repository.
MIT