Two layers per area: skills are the agent workflows (they mostly write — create and sync notes); MCP tools are the query surface (mostly read). Each is tagged R read or W writes to the vault. For end-to-end walkthroughs that chain these together, see the Guides.
Retrieval and link-graph plumbing shared by every install — the foundation the domain categories build on.
vdb-link-weaver — weave [[wiki links]] into notes by content- and title-match.vdb-note-triage — classify untyped notes, fix frontmatter, move them to the right folder.vdb-research-assistant — save clippings, synthesize notes into wiki pages, track open questions.vdb-wiki-ingestion — turn stale raw notes into synthesized wiki pages; mark sources ingested.| Tool | Purpose |
|---|---|
R vault_search | FTS5 full-text search over heading-path chunks |
R vault_semantic_search | Embedding search (when embeddings are built) |
R vault_get_chunks | Fetch content for search results |
R vault_graph | Wiki-link graph traversal |
R vault_sql | Read-only SQL query over the index |
R vault_status | DB stats — note/chunk/table counts |
The original worked examples — type: task and type: shopping notes,
plus trip and reminder workflows.
vdb-shopping — browser-assisted shopping research → decision notes.vdb-travel — trip note with linked packing, shopping, and expense lists.vdb-due-notify — surface due / approaching items to Telegram (Hermes, OpenClaw).| Tool | Purpose |
|---|---|
R vault_due_tasks | Tasks due on/before a date |
R vault_due_items | Any dated item approaching its due date |
R vault_shopping_suggestions | Frequent items from archived lists |
R vault_stale_notes | Notes updated since wiki ingestion |
R vault_publish_log | What was published outward, and when |
Ten domain tables for ops, each mapping a type: value to a parser, a table, and a
tool. The skills keep those tables fed and audited.
vdb-incident-response — create, track, and resolve incidents.vdb-incident-review — sweep stale open incidents → triage note.vdb-runbook-manager — create / update / retrieve runbooks.vdb-cert-monitor — track TLS expiry, trigger renewal tasks.vdb-host-inventory-sync — sync live host / service state into the tables.vdb-vm-health-check — cross-reference live VM / container state against the inventory; flag what's down.vdb-network-audit — audit devices against network_devices.vdb-change-log — record changes with before/after + rollback.vdb-service-dashboard — (re)generate the services dashboard page.vdb-stale-service-audit — flag unknown / unhealthy services.vdb-iac-ingestor — parse Terraform / Pulumi / CDK / Ansible into the vault.vdb-source-ingestor — scan source repos → metadata into the vault.vdb-capacity-planner — match spare hardware to a deployment goal.vdb-security-posture — audit incidents, certs, services → risk report.vdb-service-checks — checklist audit for deploys and migrations.| Tool | Purpose |
|---|---|
R vault_host_lookup | Hosts by name, IP, or status |
R vault_service_query | Running services / containers |
R vault_network_lookup | Network device lookup |
R vault_incidents | Open / resolved incidents |
R vault_runbook | Operational runbook |
R vault_spare_hardware | Spare hardware inventory |
R vault_cert_expiry | TLS certs expiring within N days |
R vault_recent_changes | Infrastructure change log |
R vault_cloud_resources | Cloud resource inventory |
R vault_source_repos | Source repository metadata |
Goals → epics → stories as plain notes. Optionally, the write tools turn it into a
pull-based queue agents work on their own — mark a story ready and an agent claims it, works
it, and reports back. The claim is atomic, so two agents never grab the same
story. Enable the "roadmap" group on the Setup tab.
vdb-po — Product-Owner skill: build and manage the vault-native ticket tree (goals, epics, stories).vdb-sprint — agent work queue: claim a ready story atomically, execute it, write status back.| Tool | Purpose |
|---|---|
R vault_roadmap_summary | Goal / epic / story rollup |
R vault_epic_stories | Stories under an epic |
R vault_ready_stories | Stories marked ready to claim |
R vault_story_candidates | Stories needing grooming |
W vault_claim_story | Claim a story atomically for an agent |
W vault_update_story_status | Write progress back to the note |
A directed graph of service / call relationships plus QA scenarios. Given a change, find the
affected scenarios and coverage gaps. Edges are derived from relationship frontmatter
(calls/publishes/reads…). Enable the "qa" group.
vdb-impact-analysis — given a change, find affected scenarios + coverage gaps.vdb-graph-sync — build / refresh graph_nodes and graph_edges.| Tool | Purpose |
|---|---|
R vault_blast_radius | What a node change can reach |
R vault_affected_scenarios | Scenarios touched by a change |
R vault_coverage_gaps | Paths with no QA scenario |
R vault_scenario_coverage | What a scenario exercises |
R vault_upstream_clients | Who calls a node |
R vault_downstream_calls | What a node calls |
Hand a task to another agent running in an isolated git worktree — interactively (a
tmux session you can take over) or fire-and-forget (a headless
systemd-run job). A durable type: handoff note seeds the agent;
each launch is recorded as a type: agent-session note. Enable the
"dispatch" group.
vdb-handoff — summarize context into a durable Handoffs/ note to save for later or pass on.vdb-handoff-session — spawn an interactive, takeoverable tmux session.vdb-dispatch — fire-and-forget headless delegation via systemd-run.| Tool | Purpose |
|---|---|
R vault_agent_sessions | List delegated sessions + their take-over command and status |
Agent attribution and the periodic reviews that synthesize what happened. The server stamps
the VAULT_AGENT env var on every query_log row, so multi-agent usage
stays distinguishable.
vdb-morning-briefing — daily briefing synthesized from vault data.vdb-weekly-review — weekly retro; saves a review note.vdb-periodic-review — monthly / quarterly strategic review.| Tool | Purpose |
|---|---|
W vault_log_activity | Log a significant agent action to DB + markdown |
R vault_activity_log | Query the activity log (date='today'|'week') |
R vault_find_note | Resolve a title to a path/ID |
The vault is the source of truth, but not an island. Stories, epics, and incidents can push to and pull from external ticketing / project-management tools (GitHub Issues, GitLab, Jira). Sync is always explicit and user-controlled — no automated background writes — so the vault and the tracker converge only when you ask.
vdb-publisher — publishing is its own skill.
Pushes vault content outward — to ticketing systems, wikis, static HTML, GitHub, or webhooks.
It always runs a dry-run first, honors hard path/tag exclusions that are never
published, and is configured through /vdb-setup. You decide what leaves the
vault. Skill source →
Agents route to MCP tools automatically when a request is vault-shaped — phrase it in terms of your content.
| Ask something like… | Tool invoked |
|---|---|
| "what tasks are due this week" | vault_due_tasks |
| "find my notes on Kubernetes networking" | vault_search → vault_get_chunks |
| "what's running on my NAS" | vault_service_query |
| "show open incidents" | vault_incidents |
| "find the runbook for Coolify" | vault_runbook |
| "what certs are expiring soon" | vault_cert_expiry |
| "what changed on pmx-01 last week" | vault_recent_changes |
| "what's the blast radius of changing auth-svc" | vault_blast_radius |
| "find notes linked to this wiki page" | vault_graph |
vault_search returns chunk IDs and scores, not content. Pass those IDs to
vault_get_chunks to read. Agents chain both automatically — "find my notes on X
and summarize them" triggers the pair.
If the agent isn't routing to MCP, name the tool:
"use vault_search to find notes about <topic>" "call vault_due_tasks for today" "query the vault database for services on <host>"
Adding a domain table is a five-place lockstep — do all five or none. Run
vdb lockstep to verify.
_init_db() — add the table nameCREATE TABLE in _init_db()_parse_X_meta() / _parse_X_items()_index() — elif note_type == "X":vault-mcp-server.py + entry in the TOOLS dictGeneric note structure (notes, chunks, links, tags, FTS) needs no changes for
new content types. See docs/setup-guide.md for the full checklist, embedding
models, and troubleshooting.