Premortem plan check
Skill kalshamsi/fable-discipline-skills/evidence/cut-skills/premortem-plan-check
11 evidence-backed process-discipline skills for Claude Code — Fable 5 working disciplines transplanted onto Opus, blind A/B validated
npx -y skills add kalshamsi/fable-discipline-skills --skill premortem-plan-checkAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Before finalizing any plan, run a premortem — assume the plan has already failed, list the likeliest causes, and reshape the plan with mitigations before presenting it. Use this whenever producing something that will be executed later: project plans, rollouts, proposals, timelines, migration or launch schedules, research plans, event logistics, hiring or content plans, implementation plans for code changes. Trigger even when the user just says "draft a plan", "give me a timeline", "how should we roll this out", or "propose an approach" without ever mentioning risk.
SKILL.md
3.2 KB, as published. Nobody here has run it
Premortem plan check
Plans drafted forward-only tend to describe the happy path, because generating steps and generating failure modes are different mental moves. Imagining the outcome as already having happened makes failure reasons easier to produce: in one study, "it failed — why?" yielded about 30% more identified reasons than "what might go wrong?" (Mitchell, Russo & Pennington 1989; single-study basis). Klein's premortem turns this into a working technique. Run that pass before the plan leaves your hands, so mitigations shape the plan instead of arriving as appended caveats.
Process
- Draft the plan as you normally would — goals, steps, sequencing, owners, dates as applicable.
- Before finalizing, switch frames: assume the plan was executed and failed outright. List the most plausible causes, as specific mechanisms ("the vendor slips delivery by two weeks"), not categories ("external risk").
- Rank the causes by likelihood and damage; keep the top two or three.
- Reshape the plan around them: add mitigations, pull risky or uncertain items earlier so failures surface while there is still time to react, and add checkpoints or fallbacks where a failure would otherwise be caught late.
- Present the reshaped plan, naming its likeliest failure modes and their mitigations inside the plan itself — a short risks section or inline notes — because a reader who executes the plan needs to know what to watch for.
What this looks like
- Product launch timeline: legal review is the likeliest slip, so it moves from week 6 to week 1 and the announcement date gets an explicit go/no-go gate.
- Research report plan: the key dataset may prove unusable, so access and quality get verified on day one, with a named fallback source before writing begins.
- Code migration: rollback is the step most likely to be untested, so the plan schedules a rollback drill before any production traffic moves.
Output rules
- Never narrate your own diligence ("I carefully considered the failure modes...", "as instructed, I..."). The premortem shows in the work product — the risks named, the sequencing chosen — not in self-description.
- Keep length proportionate to the task: a three-step plan warrants a sentence on its main risk, not a risk register.
- The failure-mode pass happens while you build the plan; only its results appear in the output — a plan whose shape reflects them, plus the top risks and mitigations where they matter.
Grounding: Klein 2007, "Performing a Project Premortem" (HBR); Mitchell, Russo & Pennington 1989 (prospective hindsight increases reasons identified; single study).