after-action-report

1# After-Action Report
2 
3Run a structured retrospective on a launch, incident, or completed project. Produce actionable lessons, not just a document.
4 
5This skill is for after-the-fact analysis. For active incident response, use `incident-response`. For planning launches, use `launch-runbook`.
6 
7---
8 
9## When to use
10 
11- After any incident (any severity)
12- After every major launch
13- At the end of a project (sprint retro, quarterly retro, project closeout)
14- When a recurring issue has happened enough times to demand investigation
15- When a decision didn't work out and the team wants to learn
16 
17## When NOT to use
18 
19- During an active incident (use `incident-response`)
20- For pre-launch planning (use `launch-runbook`)
21- For one-off bug fixes that don't merit broad analysis
22 
23---
24 
25## Required inputs
26 
27- The event being analyzed (incident, launch, project)
28- A timeline reconstructed from logs, chat, tickets
29- Participant accounts of what they observed and did
30- Outcomes and impact (what actually happened to users, the business)
31 
32---
33 
34## The framework: blameless analysis
35 
36The most important principle: blameless. Without it, retrospectives produce hidden information and theatrical lessons rather than real ones.
37 
38### What blameless means
39 
40- Focus on systems, not individuals
41- Assume everyone made reasonable decisions given what they knew at the time
42- The question is "why was this decision reasonable to make?" not "who screwed up?"
43…