Prompt library
Draft a blameless incident postmortem
System-allowed framing is what keeps postmortems generative instead of defensive, and typed action items with falsifiable done-conditions are the difference between learning and theater. The uncomfortable-question section surfaces the structural issue most postmortems politely bury.
Last reviewed July 17, 2026
The prompt
Draft a blameless postmortem from the incident notes below.
Notes: {{notes}}
Sections:
1. Summary: impact in user-visible terms (who could not do what, for how long), detection source, total duration.
2. Timeline: timestamped events from first bad deploy or trigger to full recovery. Mark gaps in my notes as [UNKNOWN: what to pull from logs].
3. Contributing causes: use "the system allowed X" framing, never "engineer Y failed to". Go at least two whys past the trigger; a config change is a trigger, not a cause.
4. What went well: detection, mitigation, communication moves worth keeping.
5. Action items: each with type (prevent recurrence, reduce blast radius, detect faster, respond faster), an owner role, and a falsifiable done-condition. Reject vague items like "improve monitoring".
6. The uncomfortable question the incident raises about our architecture or process, stated plainly.
Blameless means causes live in systems, not people; enforce that in every sentence.Run in idaptOpens a new chat with the prompt prefilled. Nothing sends until you press send.
Fill in the variables
| Variable | What it is | Example |
|---|---|---|
| {{notes}} | Timeline fragments, chat logs, metrics, whatever exists | [paste incident channel export and notes] |