mrtooher/fable-mode: a Claude skill that turns one-shot prompting into a staged, verified loop

The failure fable-mode is built around

Long agentic tasks fail in a specific way: the model announces a plan, then quietly does something else. It says it delegated to a worker and ran the task inline. It says it verified the output and means it looked at the output. The README frames the project as "execution discipline for Claude on large tasks," and the discipline is deliberately procedural rather than clever. There is a written stage map, one verifiable artifact per stage, named workers, and a check that can fail.

The intended user is someone running Claude on work where a one-shot attempt would plausibly miss something, or where the process has to be shown to someone else afterward. The README is explicit about the other side of that line: if one obvious approach fits in a single pass, staging it "buries the answer under ceremony." That sentence is doing real work. Most prompt-discipline projects never tell you when to skip them.

The core loop, and why the verification step is the load-bearing one

The loop has five steps. A numbered stage map comes first, with an expected output and one verifiable artifact per stage. It is a living document, with at most two full replans per run; a third replan means the requirements are ambiguous and the run goes back to the user. Delegation is by name: reasoning stages to a Sonnet worker, mechanical stages to a Haiku worker, cold checks to a read-only verifier. Workers do not spawn workers.

Step three is where the design has teeth. A check must be able to fail: a test that runs, a file in the expected shape, a source actually fetched, an output diffed against spec. The README states plainly that "I reviewed it and it looks right" is not a check, and requires either the exact command or the stage marked unverified. That is a real constraint, because it makes an unverified stage visible instead of letting a confident sentence stand in for evidence. Step four is a self-critique that fixes or flags a real weakness, and step five is the double-check: fresh checker agents attack the finished artifact, with ternary verdicts of PASS, FAIL or UNVERIFIABLE, and a fix-and-recheck before delivery.

The v3 change is the part worth understanding. Field feedback on v2, from r/claudeskills, was that telling a model in prose to spawn a worker almost always runs the task inline. So v3 moved the instruction out of prose and into agent definitions under agents/. The fable-orchestrator has no Write or Edit tool, so it cannot produce artifacts itself; every artifact has to come from a named worker. The verifier is read-only and receives the spec and the artifact, never the producer's reasoning. These are structural constraints rather than requests, which is the correct response to the failure mode described.

Installing fable-mode in Claude Code

The README gives a single installer for Claude Code at user scope, placing skills in ~/.claude/skills/ and agents in ~/.claude/agents/. Clone and run it:

git clone https://github.com/mrtooher/fable-mode.git && cd fable-mode && ./install.sh

After that, the skills are available to the running Claude Code session. For Cowork or claude.ai the route is manual: Settings, then Capabilities, then Skills, adding each <name>/SKILL.md, where the root SKILL.md is the fable-mode skill itself. The agents are not loadable on that surface, and the README says the skills detect this and fall back to inline mode, saying so. That fallback is the honest behavior; a skill that silently pretends to orchestrate would be worse.

One constraint is easy to get wrong. The folder name must equal the name field in each SKILL.md, or the skill will not trigger. And the README carries a warning in block-quote form that is worth repeating because it describes a concrete failure: do not install anything from agents/ as a skill. Those files are agent definitions, second-person system prompts whose frontmatter carries tools: and model:. Loaded as a skill they land in the main thread and assert things about it that are false there. The README says fable-orchestrator in particular tells its reader it has no Write tool and must delegate to worker agents that do not exist on a skill-only surface, producing a stall or an inline run narrating a delegation that never happened.

The ladder: five runners, each tuned to a known failure

fable-mode ships one skill per model rung, with the same core loop tuned to that tier's known failure mode. The ladder in the README runs Haiku, Sonnet, Opus, Fable 5.1, then the user. The default fable-mode skill runs on whatever model is active and adapts intensity. fable-fable targets Claude Fable 5.1 and is described as a provenance runner rather than an accuracy runner, for deliverables that need an audit trail or span sessions. fable-opus targets Opus for peak synthesis short of Fable, orchestrating Sonnet and Haiku workers, and guards against trusting its own introspection and against scope growth. fable-sonnet is the balanced default for thorough work and guards against skipping the failable check in favor of "looks right." fable-haiku is for bulk, cheap, parallel mechanical work and guards against skipping verification under time pressure.

Two companions are always on. execution-guardrails covers verify-before-flag, warning batching and word-boundary find-and-replace, on every model and every task whether or not the loop runs. double-check is the delivery gate, a panel of fresh checker agents where Haiku handles mechanical checks, Sonnet handles requirements and Opus adjudicates; every fable runner calls it before handing anything over. Treating the guardrails as always-on rather than opt-in is the right call, since the failures they cover are cheap to prevent and expensive to discover late.

What the benchmarks actually show, including where the skill does nothing

The README reports three benchmark rounds with deterministic graders and tasks built with unstated traps: duplicate rows, a grep-invisible getattr("calc" + "_total"), errata chains superseded by meeting notes, and a real federal data file to fetch or fabricate. The harness lives in bench/ and the README invites rerunning it.

The headline result is uncomfortable for anyone hoping for a universal improvement. On Fable 5.1 the effect is 0 delta: 100/100 in all 16 paired runs, n=2 per cell, across 4 tasks including an open-ended real-data fetch, at roughly 1.1x tokens and 2x wall time. On Opus and Sonnet the result is 0 delta on closed graded tasks but real on open-ended research, where Opus with the skill fetched and parsed the NIAAA state dataset while the Opus baseline shipped synthetic trend lines. On Haiku the effect is real but noisy, +25 and -17 across rounds, raising the floor on mechanical diligence without supplying synthesis.

The README's own reading is that the loop's value inverts with model strength: provenance on Fable 5.1, real sources over plausible ones on Opus, and verification the model would otherwise skip on Haiku, sometimes. Publishing a 0 delta for your own tool on the strongest model is unusual and it makes the rest of the table more credible. The n=2 per cell is small, and the README does not present it as anything else.

Where fable-mode is the wrong tool

The README answers this directly, which is rarer than it should be. One obvious approach that fits in a single pass should be done directly; staging a trivial task buries the answer under ceremony. The loop earns its cost only when a one-shot attempt would plausibly miss something, or when you need to show your work. Combined with the 2x wall time on the Fable tier, that is a real budget line for interactive work.

There is a second limitation in the structure itself. The orchestrator's inability to write is what enforces delegation, but it also means the orchestrator cannot make a small correction in place; a one-line fix has to travel through a worker. On a skill-only surface the whole agent layer is absent, so the discipline degrades to the inline fallback the README describes. And the benchmark table says the strongest model gains nothing measurable in accuracy, so if you are already on Fable 5.1 and do not need an audit trail, the skill is buying you process rather than results.

Alternatives, and the actual difference in approach

The nearest comparison is plain Claude Code with a hand-written system prompt or CLAUDE.md file that tells the model to plan first and verify. The difference is enforcement. A CLAUDE.md instruction lives in prose in the main thread, and the README's own field feedback says prose delegation almost always runs inline. fable-mode's response was to move the constraint into agent definitions where the orchestrator has no Write tool and the verifier never sees the producer's reasoning. If your problem is that the model ignores your instructions, a longer instruction is not the fix.

The second alternative is a general agent framework that runs the loop in code outside the model, with a real task graph and real tool sandboxing. That gives stronger guarantees than any prompt-level discipline, at the cost of leaving the Claude skill surface entirely and rebuilding your workflow around the framework. fable-mode stays inside Claude Code and Cowork, which is why it can be installed with one shell command and why its guarantees are only as strong as the runtime's agent support. If you need the stronger guarantee, you want the framework, not this.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-02, which is recent. The only listed release is v1-original from 2026-06-17, labeled as the original Fable 5 draft, so the versioning in releases does not track the v3 described in the README and V3-CHANGES.md. The README does not document a rollback path, and install.sh is described only as a Claude Code installer, so upgrading means re-running the installer or replacing the skill folders by hand. There is no migration note for someone moving from v2 to v3 other than V3-CHANGES.md.

The licence is not stated in the repository. The terms under which you may use, modify or redistribute the skill files and agent definitions are therefore unclear, and that is a gap worth resolving before this goes into a shared team setup rather than a personal one. Nothing here is legal advice; the point is simply that an unstated licence is a fact about the repository, not a detail you can assume away.

There is also a whistlepot-gateway/ directory at the top level that the README's file listing does not describe. Its purpose cannot be determined from the README, so treat it as unexplained until you read it yourself.

Editorial conclusion

Adopt fable-mode if you run Claude on multi-stage work where a one-shot attempt would plausibly miss something, or where you need an audit trail: the README's own numbers say the loop buys provenance on Fable 5.1 and real sources on Opus, while costing roughly 1.1x tokens and 2x wall time on the Fable tier. Do not adopt it for tasks that fit in a single pass, and do not install anything from agents/ as a skill, which the README says produces a stall or a narrated delegation that never happened. Before committing, verify three things yourself: that your folder name matches the name field in each SKILL.md, that your surface can load agents at all (Cowork and claude.ai cannot, and the skills fall back to inline mode), and that you accept the licence situation, which the repository does not state.

Frequently asked questions

Official sources

1. Issues
2. mrtooher/fable-mode on GitHub
3. README
4. Releases