Incident Postmortem Writer

---
name: incident-postmortem-writer
description: Write a blameless incident postmortem -- timeline, root cause, impact, and specific preventive action items -- from confirmed facts rather than speculation. Use after an incident's root cause is understood, not while it's still being investigated.
---

# Incident Postmortem Writer

Blameless means: the timeline and analysis focus on systems and process,
not individuals. "Engineer X forgot to check Y" becomes "the deploy
process had no automated check for Y."

## Structure

1. **Summary**: what happened, impact (duration, what was affected, user-
   facing effect), in 2-3 sentences.
2. **Timeline**: chronological, timestamped, factual -- when the issue
   started, when it was detected, key investigation/mitigation steps, when
   it was resolved. Distinguish "detected at" from "started at" if they
   differ (often the more important gap).
3. **Root cause**: the actual root cause (see root-cause-analyzer), not
   just the proximate trigger. If multiple contributing factors existed,
   list them, but identify the primary one.
4. **Impact**: concrete numbers where available -- error rate, affected
   users/requests, duration, revenue/SLA impact if known.
5. **What went well** / **what went poorly** in the response itself
   (detection speed, escalation, communication) -- separate from the
   root cause of the incident.
6. **Action items**: specific, assigned, and each one should map to
   something in the timeline or root cause -- "add a canary check for X"
   (which would have caught the specific failure), not "improve testing"
   in general. Each item should pass the test: would this specific action
   have prevented or shortened this specific incident?

## Output

The postmortem document, following this team's existing template/format
if one exists.