| name | vault-sweep |
| description | Comprehensive vault maintenance — cross-references blueprints against codebase state to produce a maintenance plan: archive consumed artifacts, audit docs for staleness, propose new docs for undocumented stable systems. Triggers: 'vault sweep', 'sweep the vault', 'clean up vault', 'vault maintenance', 'what can we archive', 'audit blueprints', 'vault hygiene', 'blueprint cleanup'. Use whenever the user wants a holistic view of vault health rather than archiving a single artifact (that's /archive). Also use when the user asks what's stale, what needs docs, or whether artifacts can be cleaned up. |
| argument-hint | [--execute] [--docs-only] [--no-gap-analysis] |
| allowed-tools | ["Agent","Bash","Read","Glob","Grep"] |
| user-invocable | true |
Vault Sweep
Holistic vault maintenance. Cross-references the blueprints vault against codebase reality to produce a structured maintenance plan: what to archive, what docs are stale, what stable systems deserve new reference docs.
Analytical counterpart to /archive (which operates on individual artifacts). Vault sweep surveys the whole project, classifies everything, and proposes. Nothing executes until approved.
Arguments
--execute — skip the approval gate, execute the plan immediately--docs-only — skip artifact archival, only audit docs + gap analysis--no-gap-analysis — skip the "propose new docs" phase
Phase 1: Inventory
List all active artifacts for the current project using JSON output for reliable parsing:
PROJECT_ROOT=$(git rev-parse --show-toplevel)
PROJECT_NAME=$(ct vault project)
ct spec list --json && ct plan list --json && ct review list --json && ct report list --json && ct doc list --json
Parse the JSON arrays into a combined working list. The enriched JSON includes title, created, source, and tags per artifact. Group artifacts by topic — the title field is the topic slug. Use source links to connect related artifacts (a plan's source points to its spec). Build a topic map:
topic → [{kind: "spec", name: "...", created: "...", source: "..."}, {kind: "plan", ...}, ...]
This grouping ensures related artifacts get classified and archived together. If the vault is empty or ct is not installed, report and stop.
Phase 2: Cross-reference
Determine which features are shipped. Run these in parallel:
a) Git history — merged work since the earliest artifact (use the created field from Phase 1):
git log main --oneline --since="<earliest artifact created date>" | head -120
git branch --list --no-merged main | head -50
b) Codebase verification — dispatch an Explore subagent with the topic list:
Verify which features are fully implemented and merged to main in <project-root>.
For each topic, determine:
1. Does code for this feature exist on main? (search for key types, modules, files)
2. Are there merge commits or PRs referencing it in git log?
3. Are there open branches with unmerged work for it?
Topics to classify:
<topic list with artifact counts>
Output each topic as one of:
- MERGED — fully landed on main, no open branches
- IN-PROGRESS — partial code or open branch exists
- FUTURE — design-only, no corresponding code
- UNKNOWN — can't determine (explain why)
For UNKNOWN results, investigate manually before classifying. The subagent may miss features that landed under different names than the artifact topic — especially early foundation work. Cross-check against git log.
Phase 3: Classify artifacts
Map cross-reference results onto individual artifacts:
| Classification | Criteria | Action |
|---|
| Consumed | Topic classified as MERGED | Archive candidate |
| Active | Topic is IN-PROGRESS | Leave alone |
| Future | Topic is FUTURE, no code | Leave alone |
| Living | Continuously updated docs (triage lists, needs-triage) | Leave alone |
Group consumed artifacts by feature area for the final report. One line per feature area is more useful than listing every artifact individually.
Phase 4: Doc audit
Use ct tool check-refs for deterministic staleness scoring, then read docs that need qualitative judgment.
Step 1 — Programmatic check: For each doc, run:
ct tool check-refs <doc-stem> --project-root "$PROJECT_ROOT"
This extracts file paths, backtick identifiers, and crate names from the doc body, validates each against the project filesystem, and outputs a JSON report with a staleness score (0.0–1.0).
Step 2 — Classify by staleness score:
| Staleness | Initial classification |
|---|
| < 0.10 | Likely Keep — but still read docs describing frameworks or paradigms to check for wholesale replacement |
| 0.10 – 0.50 | Likely Update — read the doc to identify which sections are stale |
| > 0.50 | Likely Archive — read the doc to confirm wholesale replacement |
Step 3 — Qualitative review: Read ALL docs via ct doc read <path>, not just those with high staleness. A doc can score 0.00 staleness while describing an entirely replaced paradigm (e.g., a Dioxus architecture doc where the app migrated to egui — paths resolve because the module names were reused, but the framework context is wrong). The staleness score catches reference drift; qualitative review catches paradigm drift.
Classify each:
| Status | Criteria | Action |
|---|
| Keep | Low staleness, content matches codebase, paradigm current | No action |
| Update | Moderate staleness or identifiable stale sections | List what needs refreshing |
| Archive | High staleness or describes a replaced paradigm | Archive with reason |
For docs marked "update," be specific about which sections are stale and what changed in the codebase. Vague "needs updating" is not actionable.
Phase 5: Gap analysis
Skip if --no-gap-analysis.
Identify stable, substantive systems that deserve reference docs. Use ct tool churn for deterministic data, then dispatch a subagent to assess documentation value.
Step 1 — Gather stability data:
ct tool churn --project-root "$PROJECT_ROOT" --since 2w --min-loc 500
This outputs per-module LOC, recent commit count, and last change date as JSON.
Step 2 — Dispatch Explore subagent with the churn data and doc list:
Assess which undocumented systems deserve reference docs.
Here is the per-module stability data (LOC, commits in last 2 weeks, last change):
<ct tool churn output>
Existing docs already cover: <list of doc topics from Phase 4>
For each module with 500+ LOC and low recent churn (≤5 commits in 2 weeks), evaluate:
- Is this system undocumented? (no corresponding doc in the vault)
- Would a developer reach for a reference doc repeatedly?
- What questions would the doc answer?
Be proactive — propose docs for every system that clears the bar. A locked binary
format, a rendering pipeline, a macro attribute reference, a theme system with 20+
configuration points — these all earn docs. Don't be conservative; the user will
cut proposals that don't make sense.
For each candidate, report:
- System name and module path
- LOC and stability evidence (from the data above)
- What the doc would cover
- Why it earns a doc
Also note systems with high churn as "revisit after stabilization" — don't propose
docs for actively churning code, but flag it for future sweeps.
The bar: would a developer reach for this doc repeatedly? Err on the side of proposing — the user will prune. Under-proposing is worse than over-proposing because it leaves undocumented systems invisible.
Phase 6: Present plan
Output a structured maintenance plan with these sections:
Archive candidates — grouped by feature area:
| Feature Area | Types Present | Count |
|---|
| Entity/World stack | spec ×2, plan ×2, review ×3, report ×2 | 9 |
| Animation system | spec, plan, review ×2 | 4 |
| Total | | N |
Doc actions — existing docs with classification and staleness score:
| Doc | Staleness | Status | Rationale |
|---|
| architecture | 0.25 | Update | Missing crates: X, Y; "Planned" section lists shipped items |
| ui-crate | 0.85 | Archive | Describes Dioxus system, app uses egui since Apr 2 |
New doc proposals (from gap analysis):
| Proposed Doc | System | ~LOC | Commits (2w) | Justification |
|---|
| rendering-pipeline | crates/renderer | 4,890 | 2 | Settled wgpu pipeline, 4-level LOD, 27 shader types |
Active artifacts — what's being left alone and why. Being explicit here builds trust. List each active/future topic with its reason (open branch, future work, living document).
End with: "Want me to execute this plan?"
Skip straight to Phase 7 if --execute was passed.
Phase 7: Execute
On approval (or --execute). Execute in this order — archival first, then updates, then new docs. Each step may affect wiki-links, so run ct vault check only at the end.
7a. Archive consumed artifacts
Use batch mode for efficiency:
ct <type> archive --batch <file1> <file2> ...
Group by artifact type (all specs together, all plans together, etc.). Each batch produces a single commit. Report progress by feature area ("Archived 22 Entity/World artifacts").
Preview first with --dry-run if the batch is large (>20 artifacts).
7b. Archive stale docs
ct doc archive <path>
7c. Update partially-stale docs
For each doc marked "update": read the current content via ct doc read, research the stale sections against the codebase, and apply targeted edits. Present each update for review unless --execute — doc updates require the most judgment.
Focus on:
- Renamed types/functions — update references to current names
- Missing crates/modules — add to architecture sections
- Framework references — correct if the framework changed
- Stale code examples — verify against current APIs
Do NOT rewrite docs wholesale. Targeted fixes to stale sections preserve the author's voice and structure.
7d. Create new reference docs
Each new doc is a research and writing task, not a copy-paste from archived artifacts. Dispatch a subagent per doc with explicit quality expectations:
Write a reference doc for <system> in <project-root>.
Read the actual source code — do NOT summarize archived specs or plans. The doc
must describe the system as it exists today.
Structure:
- **Overview**: What the system does, in 2-3 sentences.
- **Architecture**: Key types, their relationships, data flow. Use code references
(backtick identifiers) that a developer can grep for.
- **Key decisions**: Non-obvious design choices and why they were made. What would
surprise someone reading the code for the first time?
- **Common tasks**: How to add a new <thing>, modify <behavior>, debug <problem>.
Concrete steps, not abstract guidance.
Quality bar: a developer who has never seen this codebase can read this doc and
understand the system well enough to make their first change without asking someone.
Output the doc body only (no frontmatter — ct adds that).
Store with a clean topic name (no timestamps for docs). Scaffold with blueprint_create (kind=doc), Edit the body, then blueprint_commit.
Link related artifacts after creation:
RELATED=$(ct vault related --project "$PROJECT_ROOT" "<topic>")
7e. Fix broken wiki-links
Run ct vault check and review the output. Broken links fall into categories:
| Category | Action |
|---|
| Links to archived artifacts | Leave — Obsidian resolves across archive/ |
| Links to renamed files | Update the link to the new stem |
| Forward references to unwritten specs | Leave — they'll resolve when created |
| Stale cross-references | Remove the link |
Only fix links in active (non-archived) artifacts. Don't chase links inside archived files.
7f. Final report
Report summary: N artifacts archived, N docs updated, N docs created, N docs archived, N links fixed.
