retrospective

Spec §3.7's minimal retrospective engine + v2.1 D-2's skill-candidate mining, in one pass: gather → analyze → (live session may enrich) → propose_all. No eval-scored iteration — this runs once per invocation, not a tuning loop.

The three deterministic rules (analyze)

All three are pure, deterministic functions over gather()'s output — no LLM call inside lib.analyze. The judgment layer belongs to the LIVE SESSION running this skill, not the library: read each finding, optionally enrich it (a sharper lesson statement, a more concrete proposed skill shape) before calling propose_all.

When to use this skill

• Friend invokes /ren:retrospective for a fresh pass
• Friend invokes /ren:retrospective --since 2026-01-01 to scope the metrics window
• A scheduled routine invokes it periodically (via skills/routine-init's allowlist mechanism, capabilities: ["retrospective"])

Behavior

1. Call skills.retrospective.lib.gather(since=...).
2. Call analyze(gathered) — get the deterministic findings list.
3. Enrich each finding — in a worker subagent when possible (execution_tier: worker): findings are self-contained, so spawn a cheap worker-model subagent (worker-class or classifier-class) to sharpen messages and refine proposed skill shapes, and take its output back. Parse its returned JSON with lib.adapter.worker.parse_worker_json — it tolerates a ```json fence or leading prose despite raw-JSON-only instructions, and raises WorkerOutputError (carrying the raw text) if the output still isn't valid JSON. Fall back to enriching inline only when subagents aren't available; the lib layer stays mechanical either way.
4. Call propose_all(findings, session) → (entries, suggestions). lesson/instruction-tweak findings are data-plane (descriptive): each queues an ADD proposal (producer="retrospective", writer="retrospective") through propose_and_apply and lands applied immediately (entries). skill-candidate findings are instruction-plane suggestions by intent (Task 16, 0.4.2): each is recorded into the durable suggestion store (lib.suggestions.record, kind page_write) instead of the queue — fingerprinted, so re-running never re-nags a pending or already-decided candidate (suggestions).
5. Render the result to the friend: what auto-applied (already saved — say "undo <write_id>" to revert), and which skill-candidate suggestions were newly recorded for review later (via the suggestion surface).

Why writer="retrospective" is not quarantined

lib.memory.queue.apply/apply_auto's auto-quarantine (Task 2.4) only fires for writer="llm-auto". Retrospective findings are their OWN provenance class — a deterministic mining pass, judgment-enriched by a live session, is a different trust shape than raw unreviewed LLM output. Whether a finding auto-applies or waits pending is governed by the v2.2 two-plane intent split (data vs. instruction), not by quarantine — see the Behavior section above.

What this skill does NOT do

• Auto-apply a skill-candidate finding. That's an instruction-plane suggestion by intent — it always stays pending for a human's OK, regardless of which page it targets.
• Iterate against an eval score. That's explicitly out of scope per spec §3.7 — this is one pass, not a tuning loop.
• Scan transcripts unboundedly. gather() caps at the last 10 transcripts for the current project (MAX_SESSIONS_SCANNED).

References

• Task 3.1 (lib/instrument/collect.py) — the metrics surface + the transcript family this reads (same files harvest_session_usage reads, mined here for task phrases instead of token counts)
• Task 2.1 (lib/memory/queue.py) — the single write-queue every finding proposes through
• Task 2.4 (queue's auto-quarantine) — why writer="retrospective" bypasses it, see above
• skills/insights/scripts/collect.py (donor, ~/Dev/startup-framework) — the topic-extraction pieces (STOPWORDS, word regex, secret guard) adapted here
• lib/memory/revert.py — the one-step undo a friend uses on what this skill auto-applies, invoked conversationally ("undo <write_id>"), not through a queue skill