Does the skill support per-project knowledge bases?

[francislee-cn]

Goal

I want either of:

1. One knowledge base per project — each code repo has its own dedicated vault, fully isolated.
2. Multiple projects sharing one vault — separated by top-level subfolders, each project's notes confined to its own folder.

In both cases the goal is: when I work in repo A, the skill operates only on A's knowledge; when I work in repo B, only on B's.

Observations from the repo

Reading setup.sh, the hook script, and the README, the skill appears to assume one machine = one vault:

• OBSIDIAN_VAULT_PATH is written to the global ~/.claude/settings.json
• Slash commands are symlinked globally to ~/.claude/commands/
• The PostCompact hook is registered globally
• All docs and prompts reference "the vault root" as a single, fixed location
• vault_health.py and the MCP server operate over the entire vault path

Question

Does the skill support either of the two goals above out of the box? If yes, how — I couldn't find it in the docs. If no, is this intentionally out of scope?

[eugeniughelbur]

Francis — sorry for the long radio silence, this one slipped past me. Your read of the code is accurate: the skill currently assumes one machine = one vault. But you can get goal 1 (per-project KB) today, just not via the documented install path. Goal 2 is honest to-be-done.

Goal 1 — per-project vault (works today, undocumented)

Use Claude Code's per-project settings instead of the global one. Set OBSIDIAN_VAULT_PATH in .claude/settings.json inside each repo:

// in ~/projects/repo-a/.claude/settings.json
{
  "env": {
    "OBSIDIAN_VAULT_PATH": "/Users/you/vaults/repo-a-vault"
  }
}

// in ~/projects/repo-b/.claude/settings.json
{
  "env": {
    "OBSIDIAN_VAULT_PATH": "/Users/you/vaults/repo-b-vault"
  }
}

When you launch Claude Code from repo-a, the per-project setting overrides the global one. When you launch from repo-b, you get its vault. The skill's commands and hooks are globally installed, but every hook reads OBSIDIAN_VAULT_PATH from process env at fire time — verified in hooks/load_vault_context.py, hooks/validate-ai-first.sh, hooks/obsidian-bg-agent.sh — so they all operate on whichever vault the current project resolves to.

You still need each vault bootstrapped once (bash scripts/setup.sh per vault), and each vault gets its own _CLAUDE.md.

I will add this to the README and SKILL.md setup section. It is a clean recipe and you are not the first person who would want it.

Goal 2 — one vault, isolated top-level folders (not today)

This one does not work cleanly. The skill's commands have no --scope concept. /obsidian-find scans the whole vault, /obsidian-recap reads all daily notes across all folders, /obsidian-emerge looks for patterns vault-wide. Organizing top-level folders (Atlas/, RepoB/, RepoC/) gives you visual grouping and natural wikilink clusters, but it does not isolate commands.

Real isolation would mean adding a scope: field in _CLAUDE.md (or a --scope <folder> flag on every command) and threading it through ~25 commands plus the adapter regen. Not a small patch — probably 200+ lines and careful testing across all four platforms (Claude Code, Codex CLI, Gemini CLI, OpenCode).

It is worth doing eventually — multi-repo devs and consultants juggling clients would all benefit — but I am not going to start it solo. If goal 1 covers your case for now, I would recommend going that route. If goal 2 is what you actually need and you would be interested in collaborating on the scope refactor, drop a follow-up here and we can sketch the interface together before any code lands.

— Eugeniu

[eugeniughelbur]

Follow-up: the per-project recipe is documented now in PR #41 (merged). See SKILL.md → Per-Project Vaults (multi-repo workflows) and the new FAQ entry in README.md. Goal 1 from your original question is now a first-class supported config path, not a "you have to figure it out" workflow.

Goal 2 (in-vault folder isolation) is still untracked. If you want it, opening a new discussion thread with your use case would be the move — anyone watching this repo who wants the same thing can chime in there.