after-action-reportlisted

# After-Action Report Run a structured retrospective on a launch, incident, or completed project. Produce actionable lessons, not just a document. This skill is for after-the-fact analysis. For active incident response, use `incident-response`. For planning launches, use `launch-runbook`. --- ## When to use - After any incident (any severity) - After every major launch - At the end of a project (sprint retro, quarterly retro, project closeout) - When a recurring issue has happened enough times to demand investigation - When a decision didn't work out and the team wants to learn ## When NOT to use - During an active incident (use `incident-response`) - For pre-launch planning (use `launch-runbook`) - For one-off bug fixes that don't merit broad analysis --- ## Required inputs - The event being analyzed (incident, launch, project) - A timeline reconstructed from logs, chat, tickets - Participant accounts of what they observed and did - Outcomes and impact (what actually happened to users, the business) --- ## The framework: blameless analysis The most important principle: blameless. Without it, retrospectives produce hidden information and theatrical lessons rather than real ones. ### What blameless means - Focus on systems, not individuals - Assume everyone made reasonable decisions given what they knew at the time - The question is "why was this decision reasonable to make?" not "who screwed up?" - Fixing the system means the next person in that situation succe