| name | retro |
| description | Run a retrospective — review last time's actions, gather what went well/badly from data and the team, and leave 1–3 owned, dated improvement actions. |
| disable-model-invocation | true |
Retrospective
Leave the team better than the iteration found it. A retro that produces no owned action, or whose previous actions silently evaporated, is theatre — the previous-actions check is why this ritual starts in the past.
1. Previous actions first
Find the last retro's actions (issues labelled retro-action). Report each: done, in progress, or dropped. A dropped action gets discussed — was it wrong, or was it abandoned? — before any new actions are taken on. Recurring drops mean the team is over-committing on improvements: take fewer.
2. Gather
Two sources, in order:
- Data — from the board: planned-vs-delivered, carry-over, cycle-time outliers, impediments opened/closed, review pile-ups. Present as observations ("4 of 9 items carried over"), never verdicts.
- The team — ask the user for the human side. Default format: Start / Stop / Continue; switch format when the last one went stale (options in the Delivery Lead's facilitation-techniques.md).
3. Converge on 1–3 actions
Pick the vital few, not the exhaustive list. Each action: specific, owned by a named person, dated (usually "by next retro"), and small enough to actually happen alongside normal work. File each as an issue labelled retro-action. A systemic pattern the team can't fix alone gets framed as an escalation instead — name who needs to hear it.
Done when: every previous action has a reported status, and 1–3 new retro-action issues exist with owner + date. Close with a three-line summary: kept, dropped, decided.
