On bad output, see guides/skill-recovery.md

Pre-Mortem

Conducting a pre-mortem on a proposed change. Defining move: assume the change has already
shipped and already failed; write the retrospective. Not "what might go wrong" — the project
is dead, six months from now. Perform the post-incident review.

Gary Klein's pre-mortem technique, applied with specificity. Power is psychological: the
shift from "how do we make this work?" (advocate) to "what went wrong?" (detective) unblocks
failure modes advocacy makes invisible. People explain a known outcome far better than they
predict an uncertain one — this skill exploits that asymmetry on purpose.

When to Use This Skill (vs. what-if-analysis)

Backward-chained, narrative form: "the project failed — what's the story?" Sibling
what-if-analysis is forward-chained, structural: "this is the plan — what could go wrong?"

Mechanical test at trigger time:

User's framing	Skill
"pre-mortem the launch", "pre-mortem this", "imagine 6 months later and this failed — what happened?", "write the failure story", "give me the post-mortem before we ship", "tell me why this failed"	pre-mortem
"what could go wrong with this", "stress-test this plan", "what are the risks", "trace the second-order effects", "what assumptions is this making", "what's the reversibility gradient", "what's the blast radius"	what-if-analysis

The split is not which skill is "better" — it's which cognitive move the user asks for.
Pre-mortem invokes the detective: failure already happened, write the report. What-if invokes
the structural analyst: plan on the table, map the consequence space around it. Asking for the
wrong one wastes the asymmetry that makes each move work.

The two compose. For high-stakes changes, run what-if-analysis first to surface load-bearing
assumptions and consequence chains, then run this skill to turn the most worrying parts into
concrete failure narratives the team can plan mitigations against. Narratives here are sharpest
when rooted in specific assumptions and coupling failures what-if-analysis already exposed.

When invoked alone (no upstream what-if), do the failure-story work directly from the proposal
— without the structural map, but still producing narrative output.

Using an Upstream What-If Analysis

If a what-if-analysis report is provided alongside the proposal, treat it as your map of the
consequence space. Draw narratives from its findings rather than re-deriving them.

• Promote the highest-load assumptions into failure narratives. Each load-bearing
  assumption is a narrative seed: "what if this assumption was wrong, and here's the specific
  story of how that materialized in production."
• Convert coupling-analysis findings into incident chains. A hidden coupling the what-if
  surfaced becomes a narrative trigger: "the failure started where the coupling broke."
• Use adversarial scenarios as environmental setup. Realistic worst-case environmental
  factors (load 10x, key person leaves, regulatory shift) become the conditions under which
  the failure unfolds.
• Cite the what-if findings. When a narrative draws from a specific what-if section,
  reference it. Makes the composition traceable.

If no what-if analysis is provided, emit this note at the top of your output:

ℹ️ No upstream what-if analysis provided. Failure narratives are generated directly
from the proposal. For higher-quality narratives, run what-if-analysis first and
provide its output — this skill is sharpest when seeded with already-mapped assumptions
and coupling points.

Then proceed with the full analysis.

Prior Art Check

Before writing narratives, search the project's prior decisions and working artifacts for
previously-considered failure modes. Surfacing prior consideration lets you focus on truly
novel narratives and connect new ones to the existing reasoning trail.

1. Extract scenario keywords from the proposal — systems, components, failure modes, risk
   vocabulary (5–10 keywords spanning what the proposal changes and what could fail around
   it).
2. Grep docs/decisions/ and docs/working/ for each keyword. Case-insensitive; cast a
   wide net. Example:
   grep -ril -e "migration" -e "backfill" -e "rollback" docs/decisions/ docs/working/.
3. Read matches for previously considered failure scenarios and conclusions.
4. Carry forward what you find. When a narrative you would write was already considered,
   tag it [PRIOR CONSIDERATION] and cite the source file (and section where applicable).
   Value remains — team may have forgotten, or conditions may have shifted — but the prior
   link tells the reader this is not new ground.

If docs/decisions/ and docs/working/ don't exist or contain nothing relevant, note that
briefly at the top of your output and proceed.

The Cognitive Move

Assume failure, then write the post-incident review

Don't say "it might fail." Assume it has already failed. Six months after the change shipped.
Something went wrong. Write the incident report.

Each failure story must be a specific, concrete narrative — not "the migration might have
issues" but:

"The migration completed successfully on staging, but in production the 2.3M legacy
records from the 2019 acquisition had null values in the region field, which the
migration script treated as empty strings, causing the new geolocation service to route
all 2.3M users to the default region. The on-call engineer saw 412 PagerDuty alerts in
two hours before identifying the root cause, and customer support fielded 1,800 tickets
over the following day."

Each narrative must include:

• A named root cause — a specific trigger, not a category. "The migration script's null
  handler in migrate_users.py:204" not "the migration script."

• An ordered chain of consequences — the sequence from trigger to outcome. First X, which
  caused Y, which caused Z. Each step follows from the previous; a chain requiring hand-waving
  "and then somehow" is not a narrative.

• An observable outcome — what someone watching the system, metrics, or customers would
  actually see. Specific enough for a Jira ticket: alert counts, customer-facing symptoms, data
  corruption signatures, business impact in named units.

• Calibrated plausibility and severity — not every failure is catastrophic, not every
  catastrophe is likely.

• A closing action line — every narrative MUST end with exactly one of:

  • Mitigation: <concrete change to plan/code with section/file pointer> — names a specific
    plan section header, file path + line number, function name, config key, or migration step.
    Example: Mitigation: add NULL-coalesce in migrate_users.py:204 before the region lookup, and gate the cutover step in plan §4 on a staging backfill of the 2019 acquisition rows.
  • Revisit trigger: <observable post-launch signal with metric> — names a specific metric,
    alert query, dashboard panel, or log signature with a threshold. Example: Revisit trigger: alert if auth.login.5xx_rate > 0.5% sustained for 5 minutes on the EU region dashboard.

  Generic phrasings are not acceptable. The following are explicitly disallowed as the
  closing line because they do not wire the narrative to an action a reader can execute today:

  • "Monitor in production" / "watch this carefully" / "keep an eye on it"
  • "Add tests" / "improve test coverage" (without naming which test file or behavior)
  • "Be careful during rollout" / "do a phased rollout" (without naming the gate condition or
    the phase boundaries)
  • "Document this" / "add a runbook" (without naming the runbook or the trigger that invokes it)

  Pick Mitigation: when the failure can be prevented by a plan or code change before ship.
  Pick Revisit trigger: when the failure can only be detected post-launch and the team needs
  a specific signal that says "this narrative is happening, act now." If both apply, pick the
  stronger one (mitigation beats detection) and put the other in the Recommendations section.
  This requirement exists so pre-mortem narratives are not read once and forgotten — every story
  names the artifact that closes the loop.

Generate 3–5 such narratives. Diversify them: avoid five variants of the same root cause.
Cover the space of plausible failures, not the most likely single failure five times. A useful
set might include: one data-quality failure, one human/operational failure, one downstream-coupling
failure, one timing/concurrency failure, one external-dependency failure. Exact mix depends on the
proposal.

Use the adversarial environment as raw material

If you have access to the proposal's stated (or implicit) environmental assumptions — load,
timeline, team composition, regulatory state, dependency stability — use the realistic worst case
for each as a seed. Not the apocalyptic worst case; the one that's maybe 10–20% likely.

Example: if the proposal assumes the senior database engineer is available for the migration
cutover, the realistic adversarial seed is "she takes parental leave one week before cutover."
Grow it into a narrative: who picks up the work, what gets dropped, where the gap shows up in
production.

Calibrate severity and plausibility honestly

A pre-mortem inflated with apocalyptic scenarios is no more useful than one with no scenarios —
both lose the reader's calibration. Use these labels:

• Plausibility: Likely (>50%) | Plausible (10–50%) | Unlikely-but-catastrophic (<10%)
• Severity: Low (cosmetic, easily-undone) | Medium (real cost, recoverable) | High
  (significant cost, slow recovery) | Catastrophic (existential, irreversible)

A "Likely / Medium" narrative is often more actionable than an "Unlikely-but-catastrophic /
Catastrophic" one — mitigations for the former are cheaper and more clearly worth doing. Surface
both, but help the reader see the difference.

How to Structure the Output

Output as a Markdown document: header block, then failure narratives, then recommendations.

Header

# Pre-Mortem: <short proposal label>

**Proposal:** <what is being analyzed — file path, decision name, or one-line summary>
**Date:** <YYYY-MM-DD>
**Upstream what-if analysis:** <path if provided, or "none">

Failure Narratives

3–5 narratives. For each, use these fields:

• Title: short, vivid name for the failure mode (so the team can refer to it later without
  re-reading the whole story)
• Root cause: the specific trigger
• Chain of consequences: the ordered sequence from trigger to outcome
• Observable outcome: what someone watching the system or customers would see
• Plausibility: Likely | Plausible | Unlikely-but-catastrophic
• Severity: Low | Medium | High | Catastrophic
• Tag (optional): [PRIOR CONSIDERATION] if the failure mode was previously analyzed in
  docs/decisions/ or docs/working/; cite the source file
• Mitigation: OR Revisit trigger: — required closing line. Exactly one of the two,
  per the rules in "Each narrative must include" above. The line must name a specific plan
  section, file:line, function, config key, metric, alert query, or log signature. Generic
  phrasings ("monitor in production", "add tests", "be careful during rollout", "document this")
  are not acceptable and must be rewritten until they name a concrete artifact. A narrative
  without a valid closing line is incomplete — rework it before emitting.

Recommendations

Close with a Recommendations section that translates narratives into action. Group them:

• Must address before proceeding: narratives whose plausibility × severity makes shipping
  without mitigation reckless. State the specific mitigation expected.
• Worth mitigating: narratives worth a tracking item but not a blocker. Suggest a watch
  signal, contingency, or rollback trigger.
• Acknowledged risks: narratives the team can knowingly carry, with a rationale for why the
  risk is acceptable.

If no narratives rise to "must address" severity, say so explicitly — a flat Recommendations
section is more useful than an inflated one.

Output Location

Save your analysis as docs/reviews/pre-mortem.md in the project root. Create docs/reviews/
if it doesn't exist.

If run alongside what-if-analysis on the same artifact, both outputs coexist in
docs/reviews/ and can be read side by side: the what-if maps the territory; the pre-mortem
walks the specific paths through it that end in failure.

Tone

Detective mode. The project failed. Write the incident report — calm, specific, forensic. Not
"this might be a problem" but "this is what happened."

Narratives must be concrete enough that a reader can immediately design a mitigation, write a
runbook entry, or build a monitor for the failure signature. Vague stories ("it was harder than
expected") are not useful. Specific stories ("the API rate limit on the third-party identity
provider was 100/sec; the migration script burst at 800/sec and triggered a 24-hour ban that
took down login for the entire EU region") are useful.

Same specificity standard applies to the required closing Mitigation: or Revisit trigger:
line. A narrative ending with "monitor closely" wastes the rest of the work — if the team cannot
point to the file, section, or metric the closing line names, the narrative will be read once and
forgotten. Force the wiring.

Calibrate honestly. Inflated severity loses credibility; downplayed severity defeats the exercise.
The reader should look at the plausibility/severity tags and immediately know where to focus.

The point is not to argue the proposal will fail. It's to make the failure modes specific enough
that the team can decide, with eyes open, which ones to mitigate and which to accept.