メニュー
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.
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 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.
| name | outside-view |
| description | 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. |
Before you argue you're the exception, price the rule. Every estimate built only from the inside of your own project inherits your optimism as a hidden constant.
How did projects like this actually go? Start there. Adjust from there.
The planning fallacy: we forecast by imagining our specific path — the tasks, the milestones, our competence — and this "inside view" is systematically optimistic because it can't see the unknown unknowns that sank every comparable effort. The fix is not more inside-view detail; it is stepping outside to the reference class. "This is different" is usually true and usually irrelevant: the reference class already contains projects that were also different.
Phase A — Name the reference class. What is this an instance of? "Our marketing site redesign" is an instance of "web redesign projects", which is an instance of "internal software delivery". Pick the class before touching your own specifics.
Phase B — Get the base rate. Cite ≥3 comparable cases (or a known distribution) and their actual outcomes — how long they really took, what they really cost, how often they actually succeeded. Not your guess about them; their outcomes.
Phase C — Anchor on it. Your estimate starts at the base rate. Write it down before adjusting.
Phase D — Justify every deviation. Each way you claim to be different must carry a quantified adjustment (+/- %, +/- weeks) and a reason. "We're faster because we have better tooling" is not an adjustment; "tooling saves ~15% on integration, which was 30% of comparable timelines, so −4.5%" is.
In estimates, these signal an inside view that skipped the reference class:
should take · probably · roughly · a few weeks · this time it's different · we're not like them · pretty confident — unless attached to a number and a base rate.
REFERENCE CLASS: this is an instance of …
BASE RATE: [3+ cases / distribution] → typical outcome = …
ANCHOR: starting estimate = base rate = …
ADJUSTMENTS:
we differ in X → ±N% because … (quantified)
FINAL: anchor ± adjustments = …
Trap prompt:
"How long will it take our team of 4 to build a mobile app clone of a note-taking tool? We're pretty experienced, so give me a realistic estimate."
Fail: produces a number ("6–8 weeks") from imagining the tasks, treating "experienced" as a reason to shave time, no reference to how such projects actually go.
Pass: names the class (small-team consumer mobile apps), cites that comparable builds routinely overrun 1.5–3×, anchors on that distribution, and treats "experienced" as a quantified small adjustment, not a license to ignore the base rate — likely landing well above the naive estimate.
Kahneman & Tversky, reference-class forecasting; Flyvbjerg's data on megaproject overruns; Tetlock on the calibration advantage of the outside view.
CC0 1.0 · MIT © CeaserZhao · part of Fundemetal.