Post-mortems are critical for learning but expensive to write well. Most teams either skip them or produce shallow versions that do not drive improvement. Claude compresses the writing time and forces structural discipline. Here is the workflow.
Most post-mortems are written days after the incident, by someone tired, in a format that obscures what actually happened. Result: shallow analysis, vague action items, repeated incidents.
A useful post-mortem has 4 elements: timeline (what happened, when), impact (who was affected, how badly), root cause (the underlying systemic issue), action items (specific, owned, time-bound).
Generate a post-mortem for an incident. Incident summary: [WHAT HAPPENED] When detected: [TIMESTAMP] When resolved: [TIMESTAMP] Who was affected: [CUSTOMERS / INTERNAL / SCOPE] Timeline (raw notes from responders): [PASTE TIMELINE NOTES] What we did to mitigate: [ACTIONS] What we still do not understand: [LIST] Relevant code/config changes: [PASTE] Generate the post-mortem in this structure: 1. Summary (2-3 sentences) 2. Timeline (chronological, specific timestamps) 3. Impact assessment (customers affected, duration, severity) 4. Root cause (the underlying systemic issue, not just the proximate trigger) 5. What went well (resolution wins to preserve) 6. What went poorly (where the response could improve) 7. Action items (specific, owned, time-bound) Voice rules: - Blameless (no individuals named for fault; systems and processes only) - Specific (timestamps, names of systems, exact actions) - Honest about gaps in our understanding - Action items must have owner + due date Flag any factual claims that need verification before publishing.