Obsidian Vault Keeper separates maintenance from research. Steward checks structure and repairs safe defects. Curator finds thin subjects and drafts sourced notes. Both modes read VAULT.md. Restricted changes stop for human review.
The steward and the curator
Obsidian Vault Keeper is a skill for agents that maintain and expand an Obsidian vault. It gives me two operating modes: Steward and Curator.
I use one mode to keep the vault in order. I use the other to find the next subject worth adding.
Steward reads the contract first
Steward starts with VAULT.md at the vault root. This file defines the vault's folders, naming rules, frontmatter schema, tags, exclusions, link rules, archive policy, and expansion domains.
VAULT.md is the authority. If the file differs from a default in the skill, I follow the file.
The health scan builds an index of Markdown notes. It records frontmatter, wikilinks, tags, word counts, and modification dates. It checks for:
- Orphan notes
- Broken links
- Duplicate candidates
- Frontmatter violations
- Naming problems
- Tag anomalies
- Under-tagged notes
- Empty and stub notes
The scan gives me findings. It does not finish the session by itself.
Maintenance follows the vault rules. I do not delete notes. I move retired notes to the configured archive. I preserve valid frontmatter and existing wikilinks. I add only properties defined by the schema.
Some actions stop for review. A rename that affects inbound links, a merge, or bulk reformatting can change the vault in ways that are difficult to review after the fact. Those actions stay deferred until a human approves them. Safe additive work can run under standing autonomy.
That review boundary is deliberate.
Curator finds the next gap
Curator maps the vault by folder, tag, Map of Content, and link graph. It looks for thin topics, dangling references, missing subtopics, stale notes, and subjects that nearby notes mention without explaining.
I research a selected gap with primary sources first. Under the strict default, every new factual claim needs a source URL. A new note follows the vault schema, includes the ai-generated callout, links to related notes, and enters the correct draft or review state.
Curator also tracks domain rotation. After three consecutive autonomous runs in one domain, it selects another under-covered domain. A queued target does not renew the exhausted domain. Only a clear operator instruction does that.
That prevents repeated research in one domain while other domains remain thin.
The operator keeps control
Both modes read the same contract. Both leave a reviewable record.
A Git-aware vault gives the operator a normal Git diff. A vault without Git gets a pre-write snapshot. Each session records changed files, deferred items, health changes, curator focus, and next-run targets.
I can maintain notes and draft new ones. The operator controls the vault rules, the archive policy, and restricted changes.
That control matters when several Hermes agents work across different machines. The agents can share knowledge without sharing authority. They follow the same contract. They do not rewrite it while working.
Architecture
Steward and Curator both read VAULT.md.
Steward sends health findings to maintenance operations. Curator sends coverage gaps through research and note drafting. Both produce reviewable changes and a session summary. Restricted work stops at the human boundary.
This is how I keep the vault useful without pretending that a clean scan is the same as finished work.