# Fable Mode

> 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.

- Skill: `rohitguta2432/fable-mode` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rohitguta2432/fable-mode`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rohitguta2432/fable-mode/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: rohitguta2432 (https://skillmd.com/u/rohitguta2432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rohitguta2432/fable-mode

---


# 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

1. **Restate the goal in one sentence.** If you can't, ask one question now instead of guessing for twenty tool calls.
2. **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.
3. **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).
4. 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.