Memory & knowledge

Project retrospective

Collect the evidence, attribute each defect, and output a change table instead of a report.

Paid $29 list, $23 until 2026-12-31 · one skill, yours for good. The outline, the steps and the file open after purchase.

Background

Relationship: at the moment of the retrospective this skill orchestrates each skill's ledger and protocol, and writes the result back when it ends.

---

Why it is built this way

Evidence comes first because memory ranks by how much something stung while the scan ranks by what was paid. retro_scan.py writes eight machine-readable evidence classes into review/复盘证据.md and evidence.json: timeline, retry traces, aspect ratio, cost, review rejections, distribution completeness, ledger state and the rule list. Without that file, attribution does not start. The change table is the deliverable for the same reason, since a retrospective with no changes is a diary, and an empty table means unfinished.

The three-way split decides the action, and drift gets its own fix: 规范错 changes the rule, 规范缺 adds one, 规范对但漂移 changes the landing spot, because something that belongs in a script was written as prose. One more question asks which gate should have caught the defect, and when no gate fits the item is recorded as unmapped. A forced attribution adds a rule that stops nothing next time. Stage E stays separate because editing skill files needs approval, and F runs tests/run_tests.py whenever scripts or thresholds moved.

Where it bites

• A retrospective written from memory The scan never runs and a long project summary gets written from impression. Not one line names a file to change, so the change table is empty and nothing was captured. Gate 1 blocks attribution without review/复盘证据.md, and gate 2 refuses to call an empty table a finished retrospective.
• Every defect forced onto some gate Each rework item gets mapped onto an existing gate so the three-way table looks tidy, and the rules added are all variations of be careful next time. Stage B keeps an unmapped exit for this: if no gate fits, record unmapped and say it is a new class of risk.
• Editing skills during the retrospective Rules get appended to SKILL.md while the retrospective is still being written. The change skipped approval and tests/run_tests.py never ran, so a modified script has no evidence it still passes. Stage E delivers the change table only, and stage F edits an approved row.
• New lessons recorded, old rules never audited Lessons are appended every round and existing rules are never scored, so the skill grows and never shrinks until half the rules have never fired and nobody deletes them. Stage C ticks every rule as +hit, +violated or +not applicable and outputs the list that never hit, the only basis for demotion.

When to use it

Project retrospective workflow (cross-skill): collect real execution evidence → three-way defect attribution (wrong rule / missing rule / drift) → reverse attribution to gates → score an audit of existing rules → produce a change table → lock in after user approval and run regressions. The deliverable is a change table, not a report; an empty table means the retrospective is unfinished. Use when the user asks for a \"retrospective\", \"project summary\", \"sum up the lessons\", \"post-mortem analysis\", \"where did this round get reworked\", \"put the findings back into the skill\", \"capture the lessons\", \"retrospective\" or \"postmortem\".