Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From rampstack-skills
Runs structured postmortems and retrospectives for incidents, launches, and projects. Produces timelines, root cause analysis, and actionable lessons using a blameless framework.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:after-action-reportThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Run a structured retrospective on a launch, incident, or completed project. Produce actionable lessons, not just a document.
Conducts blameless postmortems for failures, outages, and incidents by documenting timelines, quantifying impact, root cause analysis (5 Whys, fishbone), and defining corrective actions with owners and deadlines.
Structures blameless post-mortems with incident timelines, impact assessment, root cause analysis, response evaluation, action items, and lessons learned. Useful after production incidents or outages.
Guides writing blameless postmortems for SEV1/SEV2 incidents using templates, timelines, root cause analysis, and action items to foster learning.
Share bugs, ideas, or general feedback.
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.
incident-response)launch-runbook)The most important principle: blameless. Without it, retrospectives produce hidden information and theatrical lessons rather than real ones.
A complete AAR covers six sections.
A 2 to 3 paragraph overview. Captures:
This is what executives read. Anyone who reads only this section should leave with the most important information.
A reconstructed timeline of events.
For incidents:
For launches:
For projects:
The timeline is the source of truth. Disagreements about what happened get resolved here.
What caused this, in plain language.
Use one or both of:
Five whys. Start with the surface symptom. Ask "why?" Repeat 5 times (or until you reach a true root). Each "why" should yield a substantive answer, not a tautology.
Example:
The fifth why often reveals the system fix. In this case: improve the review process.
Causal chain. Multiple contributing factors that combined.
No single fix addresses the incident. Multiple gaps need attention.
Factors that didn't cause the event but made it worse, or removed safety nets that would have caught it.
A "would have been caught earlier if..." factor.
Real lessons require capturing successes, not just failures.
This is not consolation. It's calibration. Things that worked here should be reinforced and replicated.
Specific, owned, dated.
| Action | Owner | Due | Type |
|---|---|---|---|
| Add alert on connection pool saturation | [name] | [date] | Monitoring |
| Add error handling checklist to PR template | [name] | [date] | Process |
| Audit other background jobs for similar issue | [name] | [date] | Code |
Action item criteria:
Action items that don't close in their committed timeframe should re-surface in the next AAR. Patterns of unclosed actions point to deeper organizational issues.
Within 1 to 2 weeks of the event. Long enough that emotions cooled and facts gathered. Short enough that memories are fresh.
For incidents: pre-decided in the response procedure. For launches: schedule on the runbook. For projects: schedule at project closeout.
Before the meeting:
Typical agenda (60 to 90 minutes):
A facilitator runs the meeting. Often the IC for an incident, or a project lead for a project. The facilitator is not the scribe.
Within a few days of the meeting. The full AAR includes all 6 sections.
Internal: post in a known location. Make searchable. Reference in onboarding.
For high-severity incidents: external summary may be appropriate (status page, customer email, public blog).
Every action item should be tracked to closure. The next AAR re-surfaces unclosed ones.
A markdown document at aar-[date]-[event-name].md.
Structure:
# AAR: [Event name]
**Date of event:** [YYYY-MM-DD]
**AAR date:** [YYYY-MM-DD]
**Severity / scope:** [SEV-1 / Major launch / Project closeout]
**Facilitator:** [Name]
**Participants:** [Names]
## Summary
[2 to 3 paragraphs]
## Impact
- Users affected: [number, segment]
- Duration: [time]
- Revenue / business impact: [if applicable]
## Timeline
[Timestamped events]
## Root cause analysis
[Five whys or causal chain]
## Contributing factors
[List]
## What went well
[List]
## Action items
| Action | Owner | Due | Type | Status |
|---|---|---|---|---|
| | | | | |
## Lessons
[Reflections that don't fit elsewhere. Often the most quotable section.]
references/aar-template.md - Fillable AAR template covering incidents, launches, and projects.