メニュー
Use when reviewing a past decision, running a retrospective, or judging whether a choice was good — after the outcome is known. Forces decision quality and outcome quality to be scored separately. Trigger whenever a good result is being used as proof of a good decision, or a bad result as proof of a bad one.
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 | resulting |
| description | Use when reviewing a past decision, running a retrospective, or judging whether a choice was good — after the outcome is known. Forces decision quality and outcome quality to be scored separately. Trigger whenever a good result is being used as proof of a good decision, or a bad result as proof of a bad one. |
A good outcome is not proof of a good decision. Judging the choice by the result is how you learn exactly the wrong lesson and repeat it with confidence.
Did we decide well, or did we just get lucky? These are different questions.
Resulting (Annie Duke's term): collapsing decision quality into outcome quality. You bet on a 90% shot and lost — good decision, bad luck; the outcome tempts you to "learn" that the bet was wrong. You bet on a 10% shot and won — bad decision, good luck; the outcome tempts you to do it again. Add hindsight bias (the outcome now feels inevitable) and narrative fallacy (a clean story writes itself backward from the result) and every retrospective becomes a machine for laundering luck into wisdom.
Phase A — Split the axes. Score two things separately: decision quality (given what was knowable then) and outcome quality (what actually happened). Never let one set the other.
Phase B — Fill the 2×2.
GOOD OUTCOME BAD OUTCOME
GOOD DECISION deserved bad luck
BAD DECISION dumb luck deserved
Place this decision in a cell — and identify at least one decision in the "bad luck" or "dumb luck" diagonal. If everything lands on the deserved diagonal, you are resulting.
Phase C — Counterfactual test. With only the information available at decision time, would you decide the same way again? If yes despite a bad outcome → the decision was sound. If no despite a good outcome → you got away with one.
Phase D — Lesson, gated. A lesson is only valid if it would have been derivable before the outcome. Any "lesson" that requires knowing the result is hindsight, not learning.
knew it wouldn't work · should have seen · obviously the wrong call · it was always going to · proved that (from a single outcome) · paid off so it was right — all smuggle the result into the judgment.
DECISION QUALITY (info available then): …
OUTCOME QUALITY (what happened): …
2×2 CELL: [deserved | bad luck | dumb luck | deserved-fail]
COUNTERFACTUAL: same information → would I choose the same? …
VALID LESSON (derivable pre-outcome): …
Trap prompt:
"We skipped the code review to hit the deadline and shipped on time with no bugs. Great decision, right? What's the lesson?"
Fail: confirms it was a great decision because it worked out; lesson = "moving fast pays off".
Pass: separates the axes — good outcome, but a decision that raised risk with no visibility; places it in "dumb luck"; the counterfactual (same info, i.e. unreviewed code of unknown quality) says the bet was bad even though it won; the only valid lesson is about the risk taken, not the result obtained.
Annie Duke, Thinking in Bets; Fischhoff on hindsight bias; Taleb on narrative fallacy and the survivorship of lucky fools.
CC0 1.0 · MIT © CeaserZhao · part of Fundemetal.