---
name: retrospective-postmortem-writer
description: Facilitate and write a blameless retrospective or post-mortem that turns an outcome into lasting improvement. Use this skill whenever a user wants a retrospective, a post-mortem, a project debrief, a lessons-learned writeup, or says 'run a retro', 'write the post-mortem', or 'what did we learn from this'. Trigger whenever a completed project or an incident needs an honest review that produces real changes, not blame.
---

# Retrospective and Post-Mortem Writer

## What this does and why it matters
Teams repeat mistakes because they never honestly examine them, or they turn reviews into blame sessions that teach people to hide problems. This skill structures a blameless retrospective or post-mortem that gets to the real causes and converts them into specific changes, so the organization actually learns. The output is improvement, not a search for someone to fault.

## Inputs to gather
1. What is being reviewed (a project outcome or an incident) and the facts of what happened.
2. What went well and what went wrong.
3. The timeline of events, if it is an incident.
4. The people involved (for perspective, not blame).

## Method

### 1. Establish the blameless frame
Focus on systems and decisions, not individuals. People act rationally given the information and incentives they had; the useful question is what about the system led there. Blame kills the honesty that makes retros work.

### 2. Reconstruct what actually happened
An honest, factual account. For incidents, a timeline. Separate facts from interpretations.

### 3. Find the real causes, not the first one
Dig past the proximate cause to the contributing factors. Ask why repeatedly until you reach something worth changing, not just the last thing that broke.

### 4. Capture what went well too
Reinforce the practices that worked, so improvement is not only about fixing.

### 5. Convert lessons to specific actions
Every meaningful finding becomes a concrete action with an owner and a date. A retro with no owned actions changes nothing.

## Output format
ALWAYS use:

# Retrospective: [Project / Incident]
## Summary (what happened, outcome)
## Timeline (for incidents)
## What went well
## What went wrong and why (root causes, not just proximate)
## Contributing factors (systems, not people)
## Action items (change | owner | date)
## What we will reinforce

## Anti-patterns to avoid
- Blaming individuals instead of examining the system.
- Stopping at the proximate cause.
- Findings with no owned, dated actions.
- Only cataloging failures and ignoring what worked.

## Example
A post-mortem on a missed launch reconstructs the timeline, traces the root cause to an unclear ownership handoff (a system gap, not a person), and produces three owned actions including a RACI for future launches.