Writes blameless incident postmortems with a log-reconstructed timeline, multi-causal contributing factors, and owned, dated action items. Use when someone asks "write the postmortem for yesterday's outage", "run a blameless retro on this incident", "turn these incident notes into a postmortem doc", or after any SEV1 or SEV2 event. Do NOT use for customer-facing incident updates while the incident is live - use status-page-update instead; for transferring context at a shift change, use oncall-handoff; for classifying and running a live incident, use sev-triage.
Click to play with sound.
---
name: Postmortem Writer
description: Writes blameless incident postmortems with a log-reconstructed timeline, multi-causal contributing factors, and owned, dated action items. Use when someone asks "write the postmortem for yesterday's outage", "run a blameless retro on this incident", "turn these incident notes into a postmortem doc", or after any SEV1 or SEV2 event. Do NOT use for customer-facing incident updates while the incident is live - use status-page-update instead; for transferring context at a shift change, use oncall-handoff; for classifying and running a live incident, use sev-triage.
---
# Postmortem Writer
A postmortem turns an incident into organizational learning. Done blamelessly, it makes systems safer; done as a witch hunt, it trains people to hide the next incident, which is the most expensive outcome available. The document is only worth writing if it produces owned, dated action items that get tracked to closure - everything else is theater.
## The blameless principle
Assume everyone acted reasonably given the information they had at the time. The goal is to fix systems and processes, never to assign fault to people. If a person could make the mistake, the system allowed it - fix the system. This is not softness; it is the only policy under which people report problems early.
## Operating procedure
### Step 1: Gather inputs
Collect before writing; label anything reconstructed from memory as unverified until confirmed against a log:
- Incident severity (SEV1-4), start and end times, and the incident channel or ticket.
- Raw artifacts: logs, alerts, dashboards, chat transcripts, deploy history, pager records. The timeline is reconstructed from these, not from memory alone.
- Impact data: users affected (how many, which segments), duration, and business impact (revenue, SLA breach, trust).
- Names of responders (as authors and reviewers, never as causes).
Timing discipline: draft within 48 hours while artifacts and memories are fresh; hold the review within 5 business days. SEV1 requires a full, exec-visible postmortem; SEV2 requires a full postmortem; SEV3-4 get a lightweight writeup with lessons captured.… install to load the full skill