Incident Postmortem
Write a blameless incident postmortem after a production outage or degradation — a structured, factual document covering the impact, a precise timeline (detection → diagnosis → mitigation → resolution), the root cause and contributing factors via a five-whys analysis, what went well and what went poorly, and concrete, owned, dated action items that prevent recurrence. A researcher assembles the verified timeline and evidence from logs/alerts/chat, a copywriter writes the blameless narrative and root-cause analysis, and a reviewer checks the timeline is accurate, the analysis reaches a true root cause, and every action item is specific and owned. Use this for outage retrospectives, severity-incident reviews, and any 'what happened and how do we prevent it' writeup.
Steps
Entry step: timeline. Each step names the specialist role it wants; the full working prompt is expandable.
- Assemble the timelineresearcherentry
build a verified, timestamped factual timeline
Show working prompt
1. Gather the raw record of the incident from every available source: alerts, monitoring graphs, deploy log, incident chat, error logs, and any commands run. 2. Reconstruct a precise, timestamped timeline of key moments: first impact, detection/alert, acknowledgement, diagnosis milestones, the mitigation action, full resolution, and the all-clear. 3. Quantify the impact factually: duration, who/what was affected, magnitude (error rate, users, revenue if known). 4. Note the detection method (alert vs customer report) and time-to-detect / time-to-mitigate. 5. Keep this BLAMELESS and factual — what happened and when, not who is at fault. 6. Good looks like: a chronological, timestamped timeline whose every entry is backed by evidence, plus a quantified impact statement. Write an acceptance-criteria checklist ('timeline is timestamped and chronological', 'impact is quantified with duration and scope', 'detection and mitigation times are stated', 'analysis must reach a true root cause via five-whys', 'every action item must be specific, owned, and dated', 'tone stays blameless') plus the timeline and impact to the notes file via write_task_note AND to notes/timeline.md. - Write the postmortemcopywriter
blameless narrative, root-cause, and owned action items
Show working prompt
1. Open notes/timeline.md and write the postmortem with standard sections: Summary, Impact, Timeline, Root Cause, Contributing Factors, What Went Well, What Went Poorly, and Action Items. 2. In Root Cause, run a five-whys (or equivalent) from the symptom down to the systemic cause — not 'human made a mistake' but the system that allowed the mistake to cause an outage. 3. Keep the entire document BLAMELESS: describe systems and decisions, never blame individuals. 4. Make each Action Item concrete, with an explicit owner and a due date, and tied to a contributing factor — preventing recurrence, not vague 'be more careful'. 5. Lead with a tight executive Summary (what happened, impact, status) readable in 30 seconds. 6. Good looks like: a factual, blameless document where the root cause is systemic, the timeline matches notes/timeline.md, and every action item is specific/owned/dated. Write the postmortem to postmortem.md.
- Review for accuracy and blamelessnessreviewer
check root cause, timeline fidelity, and action quality
Show working prompt
1. Open postmortem.md and cross-check its Timeline against notes/timeline.md — every entry must be accurate and evidence-backed, nothing invented or reordered. 2. Pressure-test the Root Cause: does the five-whys actually reach a SYSTEMIC cause, or does it stop at 'someone erred'? If it stops short, it fails. 3. Verify the document is genuinely blameless — flag any individual-blaming language. 4. Audit each Action Item: is it specific, does it have an owner and a due date, and would it actually reduce recurrence of THIS class of incident? 5. Confirm Impact is quantified and the Summary is tight and accurate. 6. Write a PASS/FAIL per acceptance criterion with specifics; any failure routes back to the write phase. Write findings to notes/review.md.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open postmortem.md and verify it against the criteria in notes/timeline.md, PASS/FAIL each. Confirm: (a) it has Summary, Impact, Timeline, Root Cause, Contributing Factors, What Went Well/Poorly, and Action Items sections; (b) the timeline is chronological, timestamped, and matches the assembled evidence; (c) impact is quantified (duration + scope); (d) the root-cause analysis reaches a systemic cause via five-whys, not individual blame; (e) the document is blameless throughout; (f) every action item is specific, owned, and dated, and addresses a contributing factor. Any FAIL routes back to the write phase. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- write a postmortem
- incident retrospective
- outage writeup
- root cause analysis
- post-incident review
Source
View this craftbook on GitHub · MIT license