What does blameless actually mean?

It means focusing on systems rather than individuals: assuming everyone made a reasonable decision given what they knew at the time, and asking 'why was this decision reasonable to make?' rather than 'who screwed up?'. Fixing the system means the next person in that situation succeeds. Blameless does not mean no accountability (action items still have owners), no hard truths (sometimes the system is broken in obvious ways), or no discomfort (real reflection is uncomfortable). Without it, retrospectives produce hidden information and theatrical lessons.

What are the six sections of a report?

Summary (a short overview of what happened, the impact, the root cause, and the top actions), timeline (the reconstructed sequence that resolves disagreements about what happened), root cause analysis, contributing factors (the gaps that made it worse or removed a safety net), what went well, and action items. Each section earns its place: skipping 'what went well', for instance, misses the calibration on what is already working and should be replicated.

How do I find the root cause?

Use five whys, a causal chain, or both. Five whys starts with the surface symptom and asks 'why?' repeatedly until you reach a true root, where each why yields a substantive answer rather than a tautology, and the deepest why often reveals the system fix (a missing error-handling checklist behind a database outage, for example). A causal chain names the multiple contributing factors that combined, where no single fix addresses the event and several gaps each need attention.

What makes an action item good?

Specific, owned, dated, sized, and closeable. 'Improve testing' is not actionable; 'add an error-handling checklist to the PR template' is. Owned means a name, not 'the team'; dated means a real date, not 'soon'; sized means a rough sense of hours, days, or weeks; closeable means the definition of done is clear. Action items that do not close in their committed timeframe should re-surface in the next report, because a pattern of unclosed actions points to a deeper organizational issue.

When should I run the review?

Within one to two weeks of the event: long enough that emotions have cooled and the facts are gathered, short enough that memories are still fresh. Gather the timeline, logs, chat, tickets, and individual written accounts before the meeting, then run a 60-to-90-minute session with a facilitator who is not the scribe. And run a report after successful launches too, not only failures, because the lessons from what worked are valuable and easy to lose.

Skill · After-action report

After-action report.

A retrospective that produces action items, not a filed document.

Run a structured retrospective on a launch, incident, or completed project. A complete report covers six sections: summary, timeline, root cause analysis, contributing factors, what went well, and action items. The whole thing rests on one principle: blameless analysis.

The point is actionable lessons. Action items are specific, owned, and dated, and the ones that never close re-surface in the next review, where a pattern of them points to something deeper than a missed task.

Audience: engineering, product, and ops teams running a postmortem after an incident, a retro after a launch, or a closeout at the end of a project.

View the skill on GitHub Browse the full catalog

The framework

Six sections of a complete report.

A complete after-action report covers all six. The summary is what executives read; the action items are what change anything.

01Summary: a 2-to-3 paragraph overview of what happened, the impact, the root cause in plain language, and the top action items. Anyone who reads only this leaves with the essentials.
02Timeline: the reconstructed sequence of events, the source of truth where disagreements about what happened get resolved.
03Root cause analysis: what caused this, via five whys, a causal chain, or both. The deepest why often reveals the system fix.
04Contributing factors: the gaps that did not cause the event but made it worse or removed a safety net (monitoring, documentation, process, tooling, knowledge).
05What went well: the detection, response, and decisions that worked. Calibration, not consolation, so the good patterns get reinforced.
06Action items: specific, owned by a name, dated, sized, and closeable. The part of the report that actually changes the system.

The principle

Fix the system, not the person.

The most important principle is blameless. Focus on systems rather than individuals, assume everyone made a reasonable decision given what they knew at the time, and ask why that decision was reasonable rather than who made a mistake. Fixing the system means the next person in the same situation succeeds where this one did not, which is the entire point of the exercise.

Blameless is not the absence of accountability. Action items still have owners, hard truths still get named when the system is broken in obvious ways, and real reflection is uncomfortable. The aim is to surface the information that fear of blame hides, not to soften the findings into something that teaches nothing.

Action items are where the report earns its keep. Each one is specific ('add an alert on connection pool saturation at 80 percent', not 'improve monitoring'), owned by a name rather than 'the team', dated with a real date, sized, and closeable with a clear definition of done. Items that never close re-surface in the next report, and a pattern of unclosed actions points to a deeper organizational issue.

Reference files

The reference that goes alongside the SKILL.md.

references/aar-template.md
A fillable after-action report template covering incidents, launches, and projects.

Browse all reference files on GitHub

Bridges to other skills

Before, during, and around the review.

This skill is the after-the-fact analysis. These cover the active event, the launch it reviews, and where the lessons go next.

During the event
incident-response
During an active incident, detection, triage, and mitigation come first. The after-action report is what runs once the incident is resolved.
Before the launch
launch-runbook
Plans and executes the launch this report later reviews. The runbook is forward-looking; the report looks back at how it went.
Where lessons land
roadmap-planning
Reviewing what shipped against what was promised feeds the next replanning cycle. The report supplies the lessons; the roadmap acts on them.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.md Browse the full catalog

Frequently asked questions.

What does blameless actually mean?: It means focusing on systems rather than individuals: assuming everyone made a reasonable decision given what they knew at the time, and asking 'why was this decision reasonable to make?' rather than 'who screwed up?'. Fixing the system means the next person in that situation succeeds. Blameless does not mean no accountability (action items still have owners), no hard truths (sometimes the system is broken in obvious ways), or no discomfort (real reflection is uncomfortable). Without it, retrospectives produce hidden information and theatrical lessons.
What are the six sections of a report?: Summary (a short overview of what happened, the impact, the root cause, and the top actions), timeline (the reconstructed sequence that resolves disagreements about what happened), root cause analysis, contributing factors (the gaps that made it worse or removed a safety net), what went well, and action items. Each section earns its place: skipping 'what went well', for instance, misses the calibration on what is already working and should be replicated.
How do I find the root cause?: Use five whys, a causal chain, or both. Five whys starts with the surface symptom and asks 'why?' repeatedly until you reach a true root, where each why yields a substantive answer rather than a tautology, and the deepest why often reveals the system fix (a missing error-handling checklist behind a database outage, for example). A causal chain names the multiple contributing factors that combined, where no single fix addresses the event and several gaps each need attention.
What makes an action item good?: Specific, owned, dated, sized, and closeable. 'Improve testing' is not actionable; 'add an error-handling checklist to the PR template' is. Owned means a name, not 'the team'; dated means a real date, not 'soon'; sized means a rough sense of hours, days, or weeks; closeable means the definition of done is clear. Action items that do not close in their committed timeframe should re-surface in the next report, because a pattern of unclosed actions points to a deeper organizational issue.
When should I run the review?: Within one to two weeks of the event: long enough that emotions have cooled and the facts are gathered, short enough that memories are still fresh. Gather the timeline, logs, chat, tickets, and individual written accounts before the meeting, then run a 60-to-90-minute session with a facilitator who is not the scribe. And run a report after successful launches too, not only failures, because the lessons from what worked are valuable and easy to lose.