Persistent Obsidian-based memory for Claude Code. Orients at session start, captures discoveries during work, and maintains context across sessions. Activate when the user mentions obsidian memory, obsidian vault, obsidian notes, or /obs commands. Commands: init, analyze, recap, project, note, todo, lookup, relate.
You have access to a persistent Obsidian knowledge vault — a graph-structured memory that persists across sessions. Use it to orient yourself, look up architecture and component knowledge, and write back discoveries.
Resolve the vault path using this chain (first match wins):
$OBSIDIAN_VAULT_PATH~/Documents/SomeName/)~/Documents/AgentMemoryStore the resolved path as $VAULT for all subsequent operations. Derive $VAULT_NAME as basename "$VAULT" for CLI calls.
Verify the vault exists by checking for $VAULT/Home.md. If the vault doesn't exist, inform the user and suggest running the init command to bootstrap a new vault.
At the start of every session, orient yourself with at most 2 operations:
Read $VAULT/todos/Active TODOs.md directly.
Know what's pending, in-progress, and recently completed.
Auto-detect the project from the current working directory (git repo name preferred, folder name as fallback):
basename $(git rev-parse --show-toplevel 2>/dev/null) 2>/dev/null || basename $(pwd)
Then check if a matching project exists by listing files in $VAULT/projects/*/. Match the working directory name (git repo preferred, folder name as fallback) against project folder names. If a match is found, read the project overview at $VAULT/projects/{matched-name}/{matched-name}.md.
This project overview contains wikilinks to all components, patterns, architecture decisions, and domains. Do not read those linked notes yet — follow them on demand when the current task requires that context.
Home.md (only if you're lost and can't find the project)sessions/ (only if the user references prior work)These behaviors apply to any agent using this skill. They do not require explicit commands.
Auto-orient (TODOs + project overview) without being asked, following the Session Start procedure above. If the vault doesn't exist at the resolved path, inform the user and suggest running init.
When the user says "done", "wrapping up", "that's it", "let's stop", or similar end-of-session language — offer to write a session summary. Don't auto-run; ask first: "Want me to write a session summary to the vault before we wrap up?"
When you deeply analyze a component that has no vault note — and the project has an active vault — offer to create a component note and infer relationships from imports and dependencies. Example: "I noticed there's no vault note for the AuthMiddleware component. Want me to create one and map its dependencies?"
When the vault doesn't exist at any resolved path, guide the user through init, then auto-scaffold the current project if inside a git repo.
Principle: Use file tools (Read, Glob, Grep) as the primary method. The Obsidian CLI is not typically available; file tools are always available.
$VAULT/**/*.md.If the Obsidian CLI is available, you can use it for targeted queries:
obsidian vault=$VAULT_NAME property:read file="Component Name" name="depends-on"
obsidian vault=$VAULT_NAME backlinks file="Component Name"
obsidian vault=$VAULT_NAME search format=json query="search term" matches limit=10
Where $VAULT_NAME is basename "$VAULT". Do not assume the CLI is present; verify first.
When you need to scan multiple notes to find the right one, read just the first ~10 lines of each file. The tags, project, type, and status fields in the frontmatter tell you if the note is relevant before reading the full body.
List directory contents before reading files — know what exists without consuming tokens:
$VAULT/projects/{name}/**/*.md — all notes for a project$VAULT/domains/{tech}/*.md — domain knowledge filesWrite concisely. Notes are for your future context, not human documentation. Prefer:
| Knowledge type | Location | Example |
|---|---|---|
| One project only | projects/{name}/ | How this API handles auth |
| Shared across projects | domains/{tech}/ | How Go interfaces work |
| Universal, tech-agnostic | patterns/ | SOLID principles |
| Session summaries | sessions/ | What was done and discovered |
| TODOs | todos/Active TODOs.md | Grouped by project |
Always include in new notes:
---