postmortemlisted

# /postmortem -- Single-Incident Postmortem **Fast-path companion to Pillar 3 (Achieve Stability).** Writes a single-incident postmortem right after a production incident, instead of waiting for a full `/stability` audit. The book's bar: every business-impacting outage gets a full, executive-visible investigation -- not a quiet fix. ## When to invoke - Immediately after a production incident is resolved, while details are still fresh - When a Sev-1/Sev-2 incident closed with "fixed it" and no written record - As the required output of an incident retro, before the team moves on ## What it checks 1. **Timeline** -- detection time, response time, mitigation time, full resolution time -- in that order, with gaps between them called out 2. **Root cause** -- the actual mechanism that caused the incident, not just the symptom that was patched 3. **Blast radius** -- what broke, for whom, for how long, and any data or revenue impact 4. **Contributing factors** -- process gaps that let this happen (missing test, missing alert, missing runbook, single point of failure) 5. **Action items** -- concrete, owned, dated follow-ups -- not just "be more careful" ## Inputs - **Incident record** -- the alert/page that fired, chat logs from the incident channel, or the user's own account of what happened and when - **Fix** -- the PR, config change, or manual action that resolved it - **Prior history** -- check whether this same failure mode has occurred before (search `incidents/`/`postmor