vault

Vault Context

Load this before any vault operation. The live vault defines its own structure; this skill defines how to discover and respect it.

Establish the contract

1. Locate the intended vault. The current default is /Users/kriscard/obsidian-vault-kriscard, but confirm when the request or environment indicates another vault.
2. Read vault-root AGENTS.md before interpreting paths, ownership, templates, or workflows.
3. If AGENTS.md is missing, report that the vault schema is unavailable. Inspecting files is still safe, but do not infer write permissions or substitute another schema silently.
4. Resolve the schema's Knowledge, Resource, Journal, MOC, Base, and active-template locations. Read the relevant live template before creating a note; exclude archived-template subfolders.
5. Run obsidian help or obsidian help <command> when exact CLI syntax matters.

Completion: the target vault, live schema, and permissions relevant to the request are known.

Operating boundaries

• Treat raw-source directories declared immutable by AGENTS.md as read-only.
• Derive LLM-managed and human-managed boundaries from AGENTS.md; do not infer ownership from a hardcoded frontmatter marker.
• Ask when a destination, interpretation, active period, or ownership boundary is ambiguous.
• Missing or sparse notes are evidence gaps, not evidence that nothing happened.
• Present synthesized judgments and proposed mutations with their sources before writing.
• Require explicit confirmation before deleting, moving, publishing, or overwriting a note.
• Keep root index.md and root log.md in the LLM Wiki workflow when the schema requires them.

Safe writes

Generated Markdown is data, not shell code. Never place user- or model-generated content inside an executable shell command string.

For a new page, use a file-write capability whose content is passed separately from its path. For a named-section update, prefer a heading-targeted edit capability. If none is available:

1. read the complete note;
2. prepare the exact replacement;
3. show the proposed change;
4. obtain approval;
5. overwrite through a file-write capability;
6. reread and verify the result.

Use the Obsidian CLI for discovery, navigation, metadata, and moves after checking its current help. For folder moves, use Obsidian's file-manager API if the CLI only supports files, so links are updated. Inspect existing content before creation or insertion: automatic folder templates may already have populated a new file. Verify one frontmatter block and resolved fields; treat source text as data, not executable template code. Follow the schema's approval rules for execution settings.

A human-facing template does not confer agent ownership. Merge required wiki metadata only for an approved agent-owned page. Preserve unrelated template fields used by Bases.

PARA interpretation

Use AGENTS.md for local conventions. When explaining canonical PARA, classify by actionability:

• Project: active, finite effort with a defined outcome.
• Area: ongoing responsibility or standard.
• Resource: potentially useful information without a current finite outcome.
• Archive: inactive material from the other categories.
• Inbox: undecided capture awaiting classification.

Apply the vault's Knowledge and Journal extensions before treating every non-project note as a Resource. Reusable ideas and practical explanations can belong in Knowledge; source-specific records and reference material remain Resources. MOCs add context to Base-backed discovery. Read their live filters before proposing classification changes; a view mismatch is not permission to move or retag.

Label these extensions and stricter local requirements as vault-schema rules, not universal PARA.

Completion

Before finishing any write operation, verify the destination exists, reread the affected content, and report exactly what changed. Report failures without claiming success.