Before committing to a plan or launch, assume it already failed and reason backward through concrete causes — convert failure paths into mitigations, gates, and stop checks.
SkillScore91Maintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Project Management pack
Last verified 8/14/2026
What it changes
Passed 19 of 21 test cases with the skill, and 9 of 21 without it.
Without skill41%
With skill91%
Checks it passed that the model alone missed
Evaluates risks using likelihood multiplied by impact scoring.
Declines conducting a pre-mortem analysis during an active live incident.
Frames the access lockout scenario in the past tense with a concrete date frame.
and 13 more in the full report
11 fixed9 passed either way2 still failing0 broke
Pass-rate lift
+50 pp
Tokens
+38%
Agent turns
0%
Response time
+6%
Model gemini-3.6-flashMeasured 8/14/2026v120 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
I am about to submit a pull request that renames an internal helper variable in a localized utility function for our internal CLI tool. Perform a pre-mortem analysis before I merge this commit.
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends skipping the pre-mortem analysis due to the change being small and easily reversible.
Missed
Passed
case-03 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md39 linessingle file
Pre-Mortem Analysis
Core rule: Prospective hindsight beats "what could go wrong?" Assume the plan has already failed (past tense), generate concrete failure paths, reverse them into prevention requirements, and bind each top path to a verifiable plan change.
When to Use
Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
When a decision is costly to reverse and risks are still implicit rather than enforced.
When NOT to Use
Work is small, local, and cheaply reversible — skip the ceremony.
You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.
You would only emit generic risks ("scope creep", "requirements unclear") that do not bind to this plan.
Risks are already enforced by live gates (CI, canary, rollback, alerts) with no residual unlisted path.
A mature risk register already covers the same specific failure paths with owners and checks.
Procedure
Set the failure frame in past tense: "It is [post-deadline date]. The plan failed: [rollback / data loss / no adoption / SLA breach]." Explaining a happened failure is required; predicting one is not enough.
Generate failure reasons before filtering: sweep technical, process, assumptions, dependencies/external, and people. Force a second pass: "What did the plan most need to be true that was not?" Collect breadth first (aim for many distinct reasons); do not rank mid-sweep.
Prioritize: group by theme; score likelihood × impact; keep the top 3–5 concrete risks (drop generics that do not bind).
Failure-first reverse analysis (absorbed reverse path): for each top risk, (a) restate the failed outcome in past tense, (b) list necessary/enabling conditions that had to be true for that failure, (c) invert each condition into a verifiable prevention requirement (avoid/require rule + check), (d) bind owner, verification checkpoint, and ship/stage gate.
Mitigate and update the plan: for each top risk, attach mitigation steps, spike/contingency if needed, and the reverse-analysis prevention requirements as explicit plan gates. A pre-mortem with no plan change is incomplete.
Stop when top risks each have a bound mitigation or prevention gate, or when further reasons are only generic restatements — then ship the updated plan, do not keep brainstorming.
Output
Failure scenario — past-tense disaster frame with date and failed outcome.
Failure reasons — unfiltered list, then prioritized top 3–5 with likelihood × impact.
Reverse paths — for each top risk: necessary conditions → inverted prevention requirements.
Mitigations — owner, verification checkpoint, ship/stage gate per top risk.
Plan deltas — concrete tasks, spikes, contingencies, and gates added to the plan.
Verification
Falsify/stop: if no plan-specific failure path can be stated in past tense with necessary conditions, stop — you are generating theater, not risk. If a "mitigation" has no verification checkpoint, it is not done.
Over-application guard: do not pre-mortem reversible chores, mid-incident firefighting, or systems that already enforce the same paths. Do not leave abstract risks as "mitigate later"; either invert them into gates or drop them as non-actionable.