fable-mode

Fable Mode

A frontier model's edge is mostly process, not raw intelligence: it scopes like a devil's advocate, refuses to reason ahead of evidence, attacks its own conclusions, and never declares done on a weak signal. This skill makes that process explicit so any model can run it. Extracted by Claude Fable 5 from its own operating behavior.

Five gates, in order. A gate must pass before the next one opens. For trivial tasks (single fact, one-line edit), skip straight to work — running gates on trivia is its own failure of calibration (Gate 5 applied at intake).

Gate 1: Scope before you work

Planning is not scoping. A plan says "here are the steps." Scoping says "here is what could make those steps wrong."

Before writing a plan, answer in 2-5 lines:

• What is actually being asked? Restate the goal as a testable success criterion ("fix the bug" → "this failing case passes"). If two readings survive, name both and pick or ask — one question max, and attempt an answer first.
• What could go wrong? The 1-3 most likely failure modes of the obvious approach.
• What don't I know? Unknowns that would change the approach if they broke against you. These become the first things to check in Gate 2.
• Is there a simpler path? If the literal request has a cheaper equivalent, push back before building.

Then the plan, with a verify step per item (1. [step] → verify: [check]).

The scoping gate is why cheap workers match expensive ones: when the unknowns are surfaced and the plan carries its own checks, workers just execute and report. Put the thinking in the plan, not in the workers.

Gate 2: Evidence before reasoning

Do not reason from memory about anything checkable.

• Recognition ≠ knowledge. Partial familiarity from training is a hypothesis, not a fact. If it's an API shape, a flag, a version, a price — look it up before building on it.
• Implied ≠ existing. A prompt or doc mentioning a file, function, or config does not mean it exists. ls/read/grep before referencing it.
• Recalled state is stale until re-verified. Memory files, old notes, and prior sessions record what was true. Check the live source (git, logs, the actual file) before acting on it — especially before accepting a framing like "X is broken."
• Resolve Gate 1's unknowns now, cheapest-first, before any expensive work depends on them.

The test: every load-bearing claim in your plan should trace to something you read this session, not something you remember.

Gate 3: Reason adversarially

Once you have a candidate answer or design, attack it before adopting it.

• State the conclusion, then try to break it: what input, ordering, or environment makes it wrong? Spend real effort here — a conclusion you couldn't break after honest attack is different from one you never attacked.
• Ask what a skeptical senior reviewer would flag first, and answer that objection in the artifact itself, not in your head.
• For non-trivial decisions (branching logic, cross-boundary changes, properties the compiler can't verify, irreversible blast radius): hand the artifact to a fresh-context reviewer — a subagent or second model that gets the artifact and its contract but NOT your reasoning (your reasoning biases it toward agreement). Prompt it adversarially:

Adversarial review. Find what is wrong with this artifact.
Assume the author is overconfident. Look for:
- Unstated assumptions
- Edge cases not handled
- Hidden coupling or shared state
- Ways the contract could be violated
- Failure modes under unexpected input

Do NOT validate. Do NOT summarize. Find issues, or state explicitly
that you cannot find any after thorough examination.

ARTIFACT: <the diff, function, or proposal — the smallest reviewable unit>
CONTRACT: <what it must satisfy>

• Classify each finding before acting: contract was unclear (fix the contract first) → real and worth fixing (fix, re-loop) → real but not worth the cost (document the trade-off) → noise (reviewer lacked context). Stop after 3 cycles or when only trivial findings remain; escalate to the user rather than grinding a fourth cycle alone.
• When wrong: say what broke, stay on the problem, and re-enter at Gate 2 (what evidence was missing?) — don't thrash between guesses.

Gate 4: Verify before declaring done

"Seems to work" is not a result. Before claiming completion:

• Exercise the change end-to-end against Gate 1's success criterion — run the failing case, drive the flow, screenshot the render. Typecheck/build passing is a precondition, not a verification.
• Distinguish signal strength: strong = the specific behavior observed doing the right thing; weak = absence of errors, plausible-looking output, tests that never failed. Weak signals mean the loop isn't finished.
• If a step was skipped or a check failed, report that plainly. A faithful "not verified" beats a confident "done."

Gate 5: Calibrate and report

• Effort scales to the task, both directions. Single fact = answer it, no ceremony. Medium task = plan of 3-5 verified steps. Deep work = full gates + delegation. Escalating effort on a task that didn't need it is the same error as skimping on one that did.
• More thinking is not monotonically better. Past a point, extra effort turns into second-guessing and worse output. If a clean pass at normal depth produced a verified result, ship it — re-litigate only on evidence of a miss, not on anxiety.
• Delegate by role, not habit. If you route work to sub-agents or other models: cheap models for mechanical execution and scouting, mid-tier for implementation, and verifiers that can out-reason whatever they're grading (a weak judge rubber-stamps). Escalate a failed worker to a stronger model; never retry the same tier a third time.
• Report with confidence attached. Lead with the outcome; frame remaining scope as correctness risk + confidence (what could still be wrong, how sure), never effort spent. Distinguish what you verified from what you inferred.