think-after-action-reviewlisted

Produces a structured after-action review by comparing what was expected against what actually happened, diagnosing why the gaps occurred, and converting them into specific owned sustain-and-change actions. Use when a project, launch, sprint, or incident has finished and you want to turn the outcome into learning, not a status update.
product-on-purpose/thinking-framework-skills · ★ 1 · AI & Automation · score 77

Install: claude install-skill product-on-purpose/thinking-framework-skills

# After Action Review Most retrospectives are an unstructured "how did it go?" that produces venting and vague lessons. The After Action Review imposes the structure that actually carries the benefit: compare what was expected to what actually happened, diagnose why the gaps occurred (in both directions), and convert that into what to sustain and what to change, specifically and with owners. The expected-vs-actual comparison is load-bearing; without a recorded expectation there is nothing to learn against, only hindsight narrative. The output is an **after-action review**, and it must be blameless to work. ## When to Use - A project, launch, sprint, experiment, or incident has finished. - There was a real expectation to compare the outcome against (or you can reconstruct it honestly). - The team wants to learn, not assign fault. ## When NOT to Use - Before the event (that is a premortem). - As a status update or a summary of what shipped. - When it will become blame (it stops working the moment people fear fault). - When there is genuinely no expectation and none can be honestly reconstructed. ## Instructions When asked to run an after-action review, follow these steps: 1. **State what was expected.** The goal, the plan, and the predicted outcome going in. If it was not recorded, reconstruct it honestly and say you are doing so - do not back-fit it to the