retrospect

Optional input: a review window ("since May") or a focus ("just the vaulty work"). Default to the span since the last retrospect.

Retrospect is the co-evolve-with-the-user step made a ritual. wiki/SCHEMA.md declares itself "co-evolved with the user" — extended when a recurring pattern in your edits or feedback isn't captured yet, pruned when a rule stops fitting. Retrospect is the scheduled pass that delivers on that promise: look back over recent work, decide what the vault's conventions and capture habits should learn from it, and propose those changes for approval.

Hold the line against two neighbours — if a finding belongs to them, hand it off and move on:

• lint (tome lint) checks page health: broken links, missing frontmatter, orphans, drift, size caps. Mechanical correctness of pages that already exist.
• gap-finding asks what knowledge is missing: topics the wiki should cover but doesn't.
• retrospect asks what the way-we-work should learn: it refines the conventions and the capture process itself, not the pages. "This link is broken" → lint. "We keep forgetting to record decisions, so SCHEMA should require it" → yours.

Conventions live in wiki/SCHEMA.md — the authority; scripts/tome.py (tome help) enforces the mechanics. tome is on PATH in Bash (the plugin's SessionStart hook puts it there) — just run tome <cmd>; if it's ever not found, fall back to python "$TOME_PLUGIN_ROOT/scripts/tome.py" <cmd>. It resolves which vault to act on via --vault / walking up from cwd / VAULT_ROOT. There is one gate: the user approves the proposed refinements before anything is written.

1. Prime, and set the window. Run tome sync to pull, then tome prime --full (skip if already primed this session). Find the last retrospect log line with grep -n "^## \[.*\] retrospect " wiki/log.md | tail -1 — its date is the window start; none found → default to the last ~30 days.

2. Gather the evidence across the window. Pull from every source available, then read for patterns, not one-offs:

   • Edits — the vault repo root, resolved the same way tome itself does (walk-up from cwd, else $VAULT_ROOT if set, else walk up from cwd looking for conventions.toml). git -C "<vault root>" log --since=<date> --stat for what changed and git -C "<vault root>" log --since=<date> -p -- wiki/ for how. Churn, reversals, and the same fix made by hand twice are the signal.
   • Activity — the wiki/log.md entries since the window start: the arc of recent work.
   • Inbox — ls inbox/ (with each file's age) for everything the capture skill has dropped since the last triage. Retrospect is the inbox's owner: nothing else drains it.
   • Feedback — your project memory store (its MEMORY.md index plus the feedback- and project-type files): the corrections and preferences you've already been told. Richest source.
   • Sessions — if your harness exposes session-history tools (e.g. list_sessions, search_session_transcripts), mine recent transcripts for corrections the user gave in conversation that never reached SCHEMA or a memory.

3. Review flagged pages. Run tome lint and pull out every STALE finding — a page whose inbound-link count and days-since-updated: both cleared conventions.toml's [staleness] thresholds (well-linked and old, together). Check each one against reality: if it's drifted, fix it with a surgical edit (its updated: lands naturally from that); if it's still accurate, affirm it by re-running tome describe <slug> "<same summary>" — no dedicated touch-only command exists, and this keeps the write flowing through tome instead of a hand-edited frontmatter field. Every flagged page gets one of the two; none silently skipped. No [staleness] section, or no findings: skip this step, nothing to review.

4. Derive the refinements. Sort what recurs into four kinds; discard one-offs (corrected once is noise, twice is a pattern):

   • Promote a recurring correction into wiki/SCHEMA.md — the user keeps steering the same way and SCHEMA is silent on it. Draft the convention.
   • Capture missed knowledge — something durable surfaced in the work but was never filed. Propose the page (or memory) and where it lands.
   • Add or prune a convention — a rule observed practice now contradicts, or one nothing has used. Propose the edit or the deletion.
   • Route each inbox item — for every file gathered in step 2, propose which page it becomes or extends (new page, or a surgical edit to an existing one), or propose deletion if it's gone stale. Every inbox item needs a proposal here, even a trivial one — none get silently skipped. Anything that's really lint or gap-finding: route it there, don't fix it here.