Incident Postmortem Writer

A postmortem has one customer: the engineer two years from now facing a similar failure at 3 a.m. This skill turns scattered incident artifacts — chat scrollback, alerts, dashboards, deploy logs — into a blameless, evidence-anchored document with a precise timeline, honest contributing factors, and action items scoped tightly enough to actually get done.

When to use this skill

• After any user-impacting outage, data incident, or security event
• After a near miss that was one lucky coincidence away from a very bad day
• When an existing postmortem draft reads as blame, vagueness, or theater and needs a rewrite
• Quarterly, to synthesize the pattern across several small incidents nobody wrote up

Workflow

1. Collect the raw record first: the incident channel export, alert timestamps, the deploy and change log, dashboards captured with their time ranges, and the commands responders actually ran. Write nothing until the evidence sits in one folder.
2. Build the timeline in a single timezone (UTC), entry by entry: timestamp, actor (role, not name), what was observed or done, and the source artifact. Mark three anchors explicitly — impact start, detection, mitigation. The gap between the first two is the detection story; between the last two, the response story.
3. Quantify impact in user terms: who could not do what, for how long, how many were affected, and any data or money involved. "Error rate spiked" is a graph, not an impact statement.
4. Identify contributing factors — plural. Ban the phrase "root cause"; complex systems fail through combinations. For each factor, keep asking "and why was that the case?" until the answer is a system property — a default, a gap, an incentive — rather than a person's action.
5. Write the counterfactuals honestly: what would have caught this earlier — a test, an alert, a review practice, a limit? What set the blast radius at this size and not bigger? Luck that helped goes in the report too, because luck is not a control.
6. Draft action items that pass the Monday test: each has an owner role, a scope achievable within a sprint or two, and a verification ("the alert fires in a staging drill"), never an aspiration ("improve monitoring"). Three excellent actions beat eleven that will rot in a backlog.
7. Circulate to responders for factual correction before wider publication — errors of fact destroy the document's authority faster than any awkward truth.
8. Close the loop later: the postmortem is done when its actions are verified complete or explicitly declined with a written reason, not when the document is published.

Output format

# Postmortem: <one-line description> — <date>

**Status:** draft | reviewed | actions-complete
**Impact:** <users affected, duration, data/money terms>
**Detection:** <how it was found; time from impact start to detection>

## Timeline (UTC)
| Time | Event | Source |

## What happened
<3-6 paragraphs of narrative, past tense, no blame>

## Contributing factors
1. <system property> — evidence: <artifact>

## What went well / What was luck

## Action items
| # | Action | Owner (role) | Verification | Due |

Guardrails

• Blameless is a constraint, not a tone: name roles and systems, never individuals — "the deploy," not "Dana's deploy"
• Every factual claim traces to an artifact; hearsay is labeled as hearsay or cut
• "Human error" is banned as a factor — ask why the system made the error easy and the recovery slow
• Do not sand down the embarrassing parts; the document's value is proportional to its honesty
• Keep speculation out of the timeline; unknowns are listed as open questions, never filled with plausible fiction

Reviewer checklist

• Timeline anchors present: impact start, detection, mitigation
• Impact stated in user terms, with numbers
• At least two contributing factors, each a system property with evidence
• Every action item has an owner role and a verification
• A stranger could learn the lesson without having been there