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 ; if it's ever not found, fall back to python "$TOME_PLUGIN_ROOT/scripts/tome.py" . 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.

1. 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 "" log --since= --stat for what changed and git -C "" log --since= -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.

1. 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 "" — 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.

1. 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.

1. Present the proposals — the one gate. Show each refinement as a concrete change: the exact SCHEMA wording, the page to create, the line to cut, the inbox item's destination — grouped by kind, each with the evidence that earns it. Recommend; don't dump every candidate. Iterate in place until the user approves, and drop what they reject.

Running unattended (a scheduled trigger, no live user to approve): skip the live gate. Instead, drop each derived proposal — including step 3's flagged-page fixes if they need judgment rather than a mechanical updated: bump — as its own tome inbox "..." capture describing the proposed change and its evidence, and stop; the next live retrospect's step 2 picks these up as ordinary inbox items and step 4 routes them from there. Never apply a SCHEMA edit, page rewrite, or convention change without a live approval.

1. Apply, log, and sync. Make the approved edits. For approved inbox routings: create or

extend the destination page (tome new / a surgical edit, same discipline as ingest step 7), then delete the inbox file once its content has landed — an inbox item is only removed after its routing lands, never before. tome log retrospect "" naming the window reviewed and what changed — this entry is the state store; the next run reads its date. tome sync -m "..." — no separate commit approval needed; step 5's approval already covered the content. Running unattended: tome log retrospect " (unattended — proposals filed to inbox)" then tome sync, since step 5's inbox captures are the only writes that happened.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: chicken-noodle-chris
• Source: chicken-noodle-chris/tome
• License: MIT

Install and usage instructions live in the source repository linked above.