pre-mortem
Pre-Mortem
Imagine the change has already shipped — and broken. You are reading the post-mortem the morning after the incident. Why did it fail?
This skill exists because the cheapest place to find a bug is in your imagination, not in production. The most expensive bugs come from confident-but-incomplete implementations: unit conversions assumed (minutes vs seconds), simultaneous webhook race conditions, mid-flight migrations breaking running jobs, scope creep removing a DialogTitle someone depended on. Each was foreseeable with five minutes of "how could this be wrong?". Pre-mortem is those five minutes, made structural.
How this fits with the rest of the workflow
Pre-mortem sits between plan approved and first commit:
- Before pre-mortem — there is a concrete plan, diff, or change to react to. If the problem is still fuzzy, diagnose first; reasoning about failure modes for the wrong problem wastes the exercise.
- After pre-mortem — a recommendation: ship as-is, harden first, or split the change.
- Neither is needed for trivial edits where the discipline becomes theater.
If a plan was just approved and the change touches shared state, the pre-mortem is the natural next step. If the user has not yet nailed down what is actually changing, suggest nailing that down first — diagnosing the wrong problem is a more expensive failure mode than any this skill catches.