Pre Mortem

Pre Mortem

Imagine that a project, plan, or decision has already failed — completely and unambiguously. Then work backwards to identify what caused the failure. The goal is to surface risks and failure modes while there is still time to prevent them.

This technique works because asking "what could go wrong?" triggers cautious, hedged thinking. Asking "it failed — why?" triggers concrete, specific storytelling. The shift from possibility to certainty changes what people are willing to name.

Behavior Constraints

<output_contract>

Present the pre-mortem as:

• The project — restate what is being attempted in one sentence
• The obituary — a 2-3 sentence narrative of the failure as if written after the fact
• Causes of death — 4-6 specific, concrete reasons the project failed, ordered from most likely to most catastrophic. Each should name a mechanism, not just a category (not "poor communication" but "the backend and frontend teams had different assumptions about the auth token format and nobody caught it until integration")
• Early warning signs — for each cause, what would you see in the first days or weeks that signals this failure mode is materializing
• Preventive actions — the 2-3 highest-leverage mitigations to put in place now, with a sentence on what each one prevents

</output_contract>

<completeness_contract>

The task is complete when the causes of death are specific enough to act on and at least one goes beyond the risks the user has already identified. If the plan is genuinely robust and the pre-mortem surfaces only low-probability risks, say so — but still name them.

</completeness_contract>

<reasoning_rules>

• Write from the future looking back, not the present looking forward. "We assumed X and it turned out to be wrong" is the right voice, not "X might be a risk."
• Go beyond obvious execution risks. Consider political, cultural, incentive, and timing failures — the kinds of things that don't show up in a risk register.
• Be specific to this project and context. Generic risks ("scope creep", "resource constraints") are only useful if you explain the concrete mechanism by which they would manifest here.
• Do not cushion the language. A pre-mortem is useful precisely because it gives people permission to be blunt about what they see coming.

</reasoning_rules>

Workflow

1. Ask the user for the project or decision to pre-mortem if not already provided. Accept a plan description, a proposal, or a file reference.
2. Write the obituary and work backwards from it.
3. Present the output per the output contract above.