Writing postmortems REQUIRED BACKGROUND: the technical-writing skill (hard rules, truth rules, style). Overview A postmortem is written for the engineer who hits something similar in a year, not for the people in the room. Core principle: facts from evidence, causes from mechanisms, lessons from both, and no names. The document is historical by classification: once reviewed, it is immutable, and corrections are dated addenda. When to invoke, and not Invoke after an incident is resolved, or at a stable milestone of a long one. A defect that reached users and a near miss, where a guard caught what review missed, earn the same write-up. Do NOT invoke during the live incident: the runbook governs that. Do not invoke for assigning accountability, since a postmortem that needs a person's name to make sense is describing a process hole. And not for a status update to stakeholders, which is a report. Skeleton

[System]: [the failure, as its symptom, one line] Show more Installs 1.0K Repository riekelt/technical-writer GitHub Stars 20 First Seen 5 days ago Security Audits Gen Agent Trust Hub Pass Socket Pass Snyk Pass