Vault Maintain
Purpose
Maintain the Markdown Vault as a concise, current, human-readable long-term source of truth.
When to Use
Use this skill when the user requests persistent changes to Vault content, including correcting current facts, consolidating duplicates, recording meaningful transitions, or creating a missing canonical note.
When Not to Use
Use vault-read for retrieval without mutation. Use vault-review when the requested outcome is an audit or findings report rather than targeted maintenance.
Principles
search before write
update > append
canonical note > duplicate note
current fact replaces stale current fact
history preserves meaningful transitions
explicit fact > inference
Treat the Markdown Vault as the source of truth. Databases, full-text indexes, embeddings, and vector stores are rebuildable retrieval aids only.
Workflow
Before Writing
- Search for existing notes about the subject.
- Identify the canonical note.
- Read the relevant current and historical context.
- Check existing facts and conflicts.
- Choose the smallest correct update location.
Make the Change
- Replace stale current facts instead of appending contradictory facts.
- Preserve a prior state in History only when the transition has long-term value.
- Create a note only when no suitable canonical note exists.
- Keep content concise, linked where useful, and understandable without private tool context.
- Give each mutable fact one canonical owner: component notes own configuration, topology notes own relationships, and the existing task note owns unfinished work. Other notes link to these instead of maintaining duplicate details or checklists.
- Keep
updatedfor document edits. When verification metadata is useful, useverifiedfor the actual observation date and describe the verified scope and evidence near the claim. Omit it when unknown; never advance it merely for reorganizing text or checking links. - Record partial checks per claim, not as whole-note or whole-system verification. Preserve unresolved conflicts and failed or unavailable checks explicitly.
- Before replacing content, check for intervening edits or use an exact-match patch; re-read on conflict instead of overwriting another edit. Return concise change results rather than repeatedly exposing full notes.
For infrastructure and project notes, this structure is a useful default, not a mandatory template:
# Title
> [!summary] Current status
## Architecture
## Current
## Operations
## Troubleshooting
## History
## Next
## Related
Verify
- Re-read every changed section.
- Check that Current has one consistent state.
- Remove or reconcile stale duplicate facts.
- Check relevant links and neighboring notes.
- Separate content/link validation from live operational checks in the completion report. A backup's existence is not proof that it can be restored.
Rules
- Do not store speculation or brainstorming as long-term current fact.
- Do not create an obvious duplicate entity note.
- Do not append new facts after stale facts in a way that leaves both appearing current.
- Do not treat History as Current.
- Preserve meaningful architecture changes, component replacements, major upgrades, important decisions, failed approaches worth remembering, and durable troubleshooting lessons.
- Do not record typos, routine restarts, trivial command output, or every temporary backup filename as History.
- Do not force every note into the recommended structure.
- Do not create or require
90-Archiveuntil the Vault actually adopts it. - Archive only with an authorized destination. Retired entities and superseded snapshots may move; paused experiments are not automatically retired, and useful History stays with active entities. Preserve inbound links, headings and attachments, and verify them after any move rather than assuming automatic link rewriting.
- Make persistent or destructive changes only within the user's authorized scope.
Completion Criteria
The canonical note reflects the current truth, meaningful transitions remain discoverable, duplicate or conflicting current facts are resolved, relevant links are sound, and the changed sections have been re-read.