p24-infra Docs

obsidian-vault-access

4 min read

Playbook: Obsidian Vault Access for Claude Agents

Scope: Local dev workstation (Windows) only. Skills are project-scoped and travel with the repo, but the live-app capability (obsidian-cli) is local-machine-only. Last updated: 2026-08-05

1. What exists today

  • Vault root: p24-infra/docs/ — an Obsidian vault was already created pointing at this folder (config at docs/.obsidian/, mirrored identically on both C:\code_2026\p24-infra and D:\code_2026\p24-infra checkouts).
  • .obsidian/ is gitignored (.gitattributes/.gitignore line 67) — this is a local, per-developer config, never shared with workers or committed.
  • Core plugins enabled: sync, bases, canvas, backlink, tag-pane, properties, templates. No community plugins installed (empty plugins/ dir).
  • Content reality check: despite the vault existing, the 217 files in docs/playbooks/ currently use zero real wikilinks and zero frontmatter/properties — plain ## headers and --- horizontal rules only. (A grep for [[...]] only matched TOML [[runners]] array-of-tables syntax in two playbooks, not wikilinks.) The vault is a viewer/editor convenience today, not a linked knowledge graph.

2. What was installed (2026-08-05)

Source: kepano/obsidian-skills (MIT license, upstream author Steph Ango).

Installed project-scoped at p24-infra/.claude/skills/ (not global ~/.claude/skills) because they’re specifically about this repo’s docs/ vault:

SkillWhat it doesRequires live Obsidian app?
obsidian-markdownCorrect Obsidian Flavored Markdown when writing/editing .md — wikilinks, embeds, callouts, frontmatter propertiesNo — pure syntax knowledge, works via normal Read/Write/Edit
obsidian-basesCreate/edit .base files (database-like views, filters, formulas)No
json-canvasCreate/edit .canvas files (JSON Canvas spec)No
defuddleExtract clean markdown from web pages (used instead of WebFetch for articles/docs)No

All four are static, filesystem-only skills — they work identically for the local session and for remote workers (bms-4, vps-i1) that check out this repo, since they only teach correct syntax for files already read/written with standard tools.

Deliberately NOT installed: obsidian-cli

Checked and confirmed not viable on this setup:

  • The obsidian CLI binary is not on PATH on this workstation.
  • Even if installed, obsidian-cli requires a running Obsidian desktop app (obsidian help talks to a live instance) — it is not a headless/vault-file tool.
  • Obsidian desktop was not running at check time (Get-Process Obsidian → false).
  • Remote workers (bms-4, vps-i1) are headless Linux boxes with no Obsidian app installed and no GUI — obsidian-cli can never work there, live-app or not.

Conclusion: obsidian-cli is a local-interactive-only tool (open Obsidian on this machine, then run obsidian ... from a session on this machine). It is not part of the worker knowledge pipeline. If you want to use it ad hoc, install it manually per the Obsidian CLI docs and open the app first — do not add it as a project skill, since it would silently fail for every remote/background agent.

3. Sync — does it help cross-machine access?

sync core plugin is enabled in docs/.obsidian/app.json, but this only matters for the Obsidian app (paid Obsidian Sync service, if configured) syncing vault content between devices where you run the desktop app. It has no bearing on worker access — workers read docs/ via git clone/git pull like any other file, which is already how they access it today. Sync is not a distribution mechanism for agents.

4. Properties/frontmatter — deferred

Adding structured properties (e.g. trigger:, escalation:, owner:) to the 217 playbooks so obsidian-bases could filter/query them as a database would be a real improvement for both human browsing and future agent filtering, but is a large, low-urgency retrofit (217 files) with no current consumer. Not done — revisit only if a concrete need appears (e.g. an agent needs to programmatically filter playbooks by category rather than grep).

5. Practical effect for agents

  • Any Claude session or worker editing docs/*.md now gets Obsidian-correct syntax (wikilinks, callouts, frontmatter) suggested/used automatically via the obsidian-markdown skill when relevant — improves consistency if/when cross-linking is adopted, but does not retroactively fix existing playbooks.
  • No agent should attempt obsidian CLI commands — the binary doesn’t exist and the skill was not installed for that reason.
  • This does not change where knowledge lives: docs/playbooks/ in git remains the source of truth. Obsidian is a local viewing/editing layer on top of the same files, not a separate store.

Escalation

None — this is a static skill install with no server/credential surface. If obsidian-cli is later wanted for interactive local use, install manually (docs/playbooks/ is not the right place to automate it, since it’s dev-workstation-only tooling).

Prevention / follow-up

  • If a future session installs more Claude Code skills project-wide, keep following the p24-infra/.claude/skills/<name>/SKILL.md convention already used by supabase, autoresearch.
  • If wikilinks/properties are ever adopted in playbooks, update this file’s §4 and consider a obsidian-bases view for playbook triage.

Graph View