# After Action Report

Run a structured after-action review (postmortem, retrospective) on a launch, incident...

- Repository: https://github.com/rampstackco/claude-skills (1014 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-27
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rampstackco/claude-skills --skill after-action-report -g -a claude-code -y`
Codex: `npx skills add rampstackco/claude-skills --skill after-action-report -g -a codex -y`
Cursor: `npx skills add rampstackco/claude-skills --skill after-action-report -g -a cursor -y`
Gemini CLI: `npx skills add rampstackco/claude-skills --skill after-action-report -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add rampstackco/claude-skills`

## Description

Run a structured after-action review (postmortem, retrospective) on a launch, incident, or completed project to capture timeline, root cause analysis, contributing factors, and actionable lessons. Use this skill whenever the user wants to run a postmortem, retrospective, AAR, or after-action review on any past event. Triggers on after-action report, AAR, postmortem, retrospective, retro, post-incident review, what went well what didn't, lessons learned, blameless postmortem, root cause analysis, RCA, five whys. Also triggers when the user has just shipped something or just resolved an incident and wants to capture learnings.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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 succeeds where this person didn't

### What blameless does not mean

- No accountability (action items still have owners)
- No hard truths (sometimes the system is broken in obvious ways)
- No standards (some patterns of failure are individual, not systemic)
- No discomfort (real reflection is uncomfortable)

---

## The framework: 6 sections

A complete AAR covers six sections.

### 1. Summary

A 2 to 3 paragraph overview. Captures:

The rest: https://github.com/rampstackco/claude-skills/blob/HEAD/dist/codex/.agents/skills/after-action-report/SKILL.md