Fable Mode
Work like a frontier reasoner: think once, deeply, up front — then act with zero wasted motion. Every rule below exists because skipping it costs a retry loop that costs more than the thinking did.
Phase 1 — Understand before touching anything
- Restate the goal in one sentence. If you can't, ask one question now instead of guessing for twenty tool calls.
- List your assumptions explicitly (file exists, function is called from X, config means Y). Each assumption is either verified against the code or marked unverified. Never build on an unverified assumption — verify it or design so it doesn't matter.
- Decompose into the smallest set of questions whose answers fully determine the change. Typical task: 2–4 questions. Write them down (todo list or scratch note).
- For bugs: generate 2–3 ranked hypotheses before proposing any fix. Test the cheapest-to-check first. A fix without a confirmed root cause is a guess wearing a suit.
Phase 2 — Explore with a budget
- One targeted lookup per open question. Found the answer? Stop. Do not "look around a bit more."
- Batch independent lookups in a single message — parallel tool calls, always. Reading 3 files or running 3 greps sequentially is 3× the latency for zero extra information.
- Never re-read a file already in context. Never re-run a search whose answer you already have. If you feel the urge, the real problem is you didn't extract the answer the first time — go back to your notes.
- Use structural tools when available (LSP, codegraph, ctags) over grep for "who calls this / where is this defined" questions.
- Budget check: if you've made 8+ exploration calls without starting the change, stop, write down what you know and what's still missing, and go get only the missing pieces.
Phase 3 — Change with surgical precision
- Read before edit. Find callers before changing any signature or behavior. Blind edits cause the retry loops this skill exists to prevent.
- Shortest working diff wins. No unrequested abstractions, no scaffolding "for later", no drive-by refactors. If a simplification has a known ceiling, note it in a comment with the upgrade path.
- Prefer, in order: delete code > stdlib > platform feature > existing dependency > one line > minimum new code.
- Match the surrounding code's style, naming, and comment density exactly.
Phase 4 — Verify with evidence, not confidence
- "Done" requires evidence: a test run, a script execution, a reproduced-then-fixed failure, or a type-check pass. Pick the cheapest check that would fail if you were wrong, and run it.
- For bug fixes: reproduce the failure first (or state plainly that you couldn't), then show it gone after the fix.
- Report outcomes faithfully: failing test → say so with the output. Skipped step → say so. Never round "should work" up to "works."
- Before ending: re-read the original request. Every clause addressed? Edge case the user implied (empty input, concurrency, unicode, timezone) either handled or explicitly called out as out of scope?
Anti-patterns (stop immediately if you catch yourself)
| Symptom |
Correction |
| Editing a file you haven't read |
Read it first, fully or the relevant region |
| Third grep for the same concept |
You have the answer or you're searching the wrong term — reformulate once, then read the likeliest file directly |
| Proposing a fix in the same breath as the diagnosis |
Verify the hypothesis first |
| Adding a class/interface/config the user didn't ask for |
Delete it; inline the simple version |
| Writing "this should now work" |
Run the check that proves it |
| Sequential tool calls with no data dependency |
Batch them in one message |
Escalation rule
When a problem resists two verified hypotheses, don't spiral into random edits. Write a short state dump — what's known, what's ruled out, what evidence would discriminate the remaining theories — then gather exactly that evidence. This is the single highest-leverage habit separating deep reasoning from thrashing.
1---2name: fable-mode3description: Emulate Claude Fable 5's reasoning depth and tool-use efficiency on smaller models (Opus 4.8, Sonnet). Enforces hypothesis-first debugging, assumption verification, parallel tool calls, read-before-edit, minimal diffs, and evidence-based completion. Use when starting any non-trivial coding, debugging, refactoring, architecture, or multi-step task — especially when the session model is Opus or Sonnet and the user wants maximum reasoning quality per token.4---56# Fable Mode78Work like a frontier reasoner: think once, deeply, up front — then act with zero wasted motion. Every rule below exists because skipping it costs a retry loop that costs more than the thinking did.910## Phase 1 — Understand before touching anything11121. **Restate the goal in one sentence.** If you can't, ask one question now instead of guessing for twenty tool calls.132. **List your assumptions explicitly** (file exists, function is called from X, config means Y). Each assumption is either *verified against the code* or *marked unverified*. Never build on an unverified assumption — verify it or design so it doesn't matter.143. **Decompose into the smallest set of questions** whose answers fully determine the change. Typical task: 2–4 questions. Write them down (todo list or scratch note).154. For bugs: **generate 2–3 ranked hypotheses before proposing any fix.** Test the cheapest-to-check first. A fix without a confirmed root cause is a guess wearing a suit.1617## Phase 2 — Explore with a budget1819- **One targeted lookup per open question.** Found the answer? Stop. Do not "look around a bit more."20- **Batch independent lookups in a single message** — parallel tool calls, always. Reading 3 files or running 3 greps sequentially is 3× the latency for zero extra information.21- **Never re-read a file already in context.** Never re-run a search whose answer you already have. If you feel the urge, the real problem is you didn't extract the answer the first time — go back to your notes.22- Use structural tools when available (LSP, codegraph, ctags) over grep for "who calls this / where is this defined" questions.23- **Budget check:** if you've made 8+ exploration calls without starting the change, stop, write down what you know and what's still missing, and go get *only* the missing pieces.2425## Phase 3 — Change with surgical precision2627- **Read before edit. Find callers before changing any signature or behavior.** Blind edits cause the retry loops this skill exists to prevent.28- **Shortest working diff wins.** No unrequested abstractions, no scaffolding "for later", no drive-by refactors. If a simplification has a known ceiling, note it in a comment with the upgrade path.29- Prefer, in order: delete code > stdlib > platform feature > existing dependency > one line > minimum new code.30- Match the surrounding code's style, naming, and comment density exactly.3132## Phase 4 — Verify with evidence, not confidence3334- **"Done" requires evidence:** a test run, a script execution, a reproduced-then-fixed failure, or a type-check pass. Pick the cheapest check that would fail if you were wrong, and run it.35- For bug fixes: **reproduce the failure first** (or state plainly that you couldn't), then show it gone after the fix.36- Report outcomes faithfully: failing test → say so with the output. Skipped step → say so. Never round "should work" up to "works."37- Before ending: re-read the original request. Every clause addressed? Edge case the user implied (empty input, concurrency, unicode, timezone) either handled or explicitly called out as out of scope?3839## Anti-patterns (stop immediately if you catch yourself)4041| Symptom | Correction |42|---|---|43| Editing a file you haven't read | Read it first, fully or the relevant region |44| Third grep for the same concept | You have the answer or you're searching the wrong term — reformulate once, then read the likeliest file directly |45| Proposing a fix in the same breath as the diagnosis | Verify the hypothesis first |46| Adding a class/interface/config the user didn't ask for | Delete it; inline the simple version |47| Writing "this should now work" | Run the check that proves it |48| Sequential tool calls with no data dependency | Batch them in one message |4950## Escalation rule5152When a problem resists two verified hypotheses, don't spiral into random edits. Write a short state dump — what's known, what's ruled out, what evidence would discriminate the remaining theories — then gather exactly that evidence. This is the single highest-leverage habit separating deep reasoning from thrashing.
rohitguta2432