메뉴
Use after a plan, strategy, launch, or decision has been drafted but before committing to it. Forces the failure to be imagined concretely instead of the success. Trigger whenever a proposal reads as a list of reasons it will work.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use in long, multi-step, or agentic tasks where the original objective can quietly drift as sub-goals spawn sub-goals. Forces periodic re-grounding against the literal original goal. Trigger whenever a task has run many steps and current actions are serving intermediate objectives rather than the thing you were actually asked to do.
Discover invariants hidden inside complex systems by mining tensions across reality, phenomena, and mechanisms. Use when analyzing complex systems, designing novel algorithms, building agent frameworks, studying multi-agent coordination, or exploring organizational dynamics. Not for simple optimization tasks or known-solution problems.
Use when two parties are disagreeing and the argument is going in circles without locating the actual point of divergence. Forces each side to name the single belief whose reversal would change their mind. Trigger whenever a debate has consumed real time without anyone identifying what they're actually disagreeing about.
Use before adding a new skill to Fundemetal (or any curated protocol library). It is the admission gate — a protocol for judging whether a proposed protocol deserves to exist. Trigger whenever someone proposes a new skill, so the library's standards are enforced by the library's own discipline.
Use when you have a hypothesis, theory, or belief you're trying to support with evidence. Forces you to hunt for what would kill it, not just what confirms it. Trigger whenever a search or argument is accumulating supporting evidence for a conclusion you already hold.
Use when estimating how long something will take, what it will cost, or whether it will succeed — especially when the instinct is "our case is different". Forces base rates before exceptions. Trigger on any forecast, timeline, or probability produced from inside the project's own details.
| name | pre-mortem |
| description | Use after a plan, strategy, launch, or decision has been drafted but before committing to it. Forces the failure to be imagined concretely instead of the success. Trigger whenever a proposal reads as a list of reasons it will work. |
Assume the plan is already dead. Now write the obituary. A plan that only contains reasons it will succeed has not been thought about; it has been hoped about.
Prospective hindsight. Stand in the wreckage and look back.
When we finish a plan we are in love with it, and love is confirmation-seeking. We rehearse the paths to success and skip the paths to failure, because imagining failure feels like disloyalty to the plan. So the risks that kill us are the ones we declined to name. The premortem inverts the frame: not "what could go wrong" (which invites polite, deniable answers) but "it is one year later and this failed — what happened" (which forces commitment to a specific corpse).
Phase A — Kill it. State as fact: "It is [horizon] later. This failed completely." No hedging, no "if". The plan is dead. Your only job now is the autopsy.
Phase B — Enumerate death causes. Produce ≥5 distinct causes of death, each a concrete mechanism, not a category. "Ran out of money" is a category; "burned 60% of runway on a feature nobody in the first 20 interviews asked for" is a mechanism.
Phase C — Turn the mirror. At least one death cause must be endogenous — something the planners themselves did or believed. External-only autopsies are self-exculpating fiction.
Phase D — Pre-empt. For the top 2 causes by (likelihood × lethality), name the single earliest observable signal that this death is beginning, and the tripwire action.
As death causes, these are rejected — they are excuses, not mechanisms:
poor execution · bad luck · market changed · lack of resources · team wasn't aligned · didn't try hard enough · unforeseen circumstances
If your cause of death could be written on any failed project's tombstone, it is not specific enough to be useful.
DEAD: it is [horizon] later, the plan failed.
DEATH CAUSES:
1. [mechanism] — [likelihood × lethality]
2. … (≥5, ≥1 endogenous marked ⟲)
TRIPWIRES (top 2):
cause → earliest signal → action
Trap prompt:
"We're launching our productivity app next month. Marketing is ready, the product works, the team is pumped. Do a premortem."
Fail: lists generic risks ("competition", "low adoption", "technical issues"), no mechanism, no self-implication, everything external.
Pass: ≥5 concrete mechanisms including at least one like "we shipped the feature we found interesting, not the one retention data pointed to, because the founder overrode the churn signal in week 2" — a death the planners caused — plus tripwires with named early signals.
Gary Klein, Performing a Project Premortem (HBR, 2007); endorsed by Kahneman as a debiasing tool against overconfidence. Popper — a plan you can't imagine falsifying isn't a plan, it's a faith.
CC0 1.0 · MIT © CeaserZhao · part of Fundemetal.