| name | iteration-review |
| description | Close an iteration facing the stakeholders — demo what shipped against the goal, state what didn't and why, and collect the feedback that reorders the backlog. |
| disable-model-invocation | true |
Iteration review
Close the iteration outward — this ritual faces stakeholders, where /retro faces the team's process. The deliverable is an honest account of the iteration against its goal, and the feedback it provokes.
1. Assemble the account
From the board (via the board skill), for the closing iteration:
- The goal, verbatim, and a one-word verdict: met / partially / missed.
- Shipped — Done items, each as the user-visible behaviour it enabled (the ticket's "what it delivers"), never as a task list. Link the demo evidence: the PR, the deployed surface, a recording if one exists.
- Not shipped — committed items that didn't finish, each with the real reason (blocked / underestimated / displaced by X), not a euphemism. This list is what makes the shipped list believable.
- Numbers — planned vs delivered, carry-over count. One line.
2. Present and collect
Walk the user (and their stakeholders) through it shipped-first. Then collect reactions per shipped item: keep going / change direction / stop. Feedback that implies new work becomes backlog issues on the spot — labelled, on the board, not scheduled (that's the Product Manager's pull, next /planning).
Done when: the account exists as a comment on the iteration's pinned issue (or a docs/reviews/<iteration>.md when there's none), every committed item appears in shipped or not-shipped, and every piece of feedback is either a filed issue or an explicit "noted, no action".
