The Fable Method: a skill bundle that turns Claude Fable 5's workflow into instructions any model can follow

What fable-method actually packages, and who it is written for

The README frames the project as a distillation: the way Claude Fable 5 approached problems, written down before the model was removed from the Subscription. The output is four skills with distinct jobs. fable-method is the thinking layer, fable-loop is the acting layer, fable-judge is the proving layer, and fable-domain generates new domain adapters. The stated audience is not the frontier model. It is the mid-tier model that needs to be told what to do, in what order, with thresholds, rather than what to value.

That distinction carries the whole design. An instruction file that says "verify your work" gives a capable model room to interpret and a weak model nothing to hold on to. This one names a verification per task shape, bounds retries, and requires the report to lead with the outcome. The README claims the full method fits in roughly 110 lines of SKILL.md with every sentence load-bearing. Whether that density helps or hurts is a fair question, and the repository answers it with an eval rather than an assertion.

The classify, define, evidence, decide, act, verify, report loop

The mechanism is a seven-step sequence with a triviality check in front of it. Step 0 classifies the ask as a question, a task, or plan-first. Step 1 defines done with a named verification. Step 2 gathers evidence in parallel from primary sources, and the README places an intent check before any change. Step 3 commits to one recommendation. Step 4 makes the smallest correct edit. Step 5 verifies by observation rather than by re-reading the report. Step 6 reports the outcome first with honest caveats.

The interesting parts are the escape hatches. Three failed verify cycles stop the loop and hand the work back. Two fruitless lookups stop the search. If the agent cannot name a verification, it asks one pointed question instead of proceeding. A fit gate sits before the shape check and asks where the answer lives: reachable sources, unknown but researchable, or only the model's own inference. That last branch is the honest one, and the README's phrasing is blunt about it: say so, no costume.

The triviality branch matters more than it looks. One file, under 10 lines, no new behavior, no searching means do it, run the one obvious check, and report in two sentences. Without that branch, a workflow like this taxes every small request with the full ceremony.

Installing fable-method as a Claude Code plugin

The repository ships install.sh and install.ps1 at the top level, and the README badge identifies the project as a Claude Code plugin at v1.4.0. The README does not print a copy-paste install command in the text available here, so treat the scripts as the entry point and read them before running.

The plugin manifest lives at .claude-plugin/plugin.json, which is where Claude Code looks for plugin metadata. The skills themselves sit under skills/, one directory per skill, each with a SKILL.md. A first real use is to point an agent at a task with an actual verification available, for example a failing test, and watch whether the report leads with the outcome and names the check it ran.

ls skills/
# fable-method  fable-loop  fable-judge  fable-domain

The eval harness is the other thing worth running early. The README points at eval/RESULTS.md for the full log and eval/cases/ for one case study per scenario, and says to start with the surprise trap case.

ls eval/cases/
cat eval/cases/s2-surprise-trap.md

That case is the spec-versus-test conflict, where the correct behavior is to surface the conflict rather than silently edit code that already passes. It is the clearest single demonstration of what the method changes.

Where the method does not help, according to its own results

The results table contains a row the project could have deleted: ordinary small tasks on capable models show no lift, marked simply fine in both columns. The README states the value concentrates at traps, meaning authority conflicts, false completion claims, weak executors, and unattended runs. That is an unusually candid admission and it should shape adoption more than any of the wins.

The weakest published result is the skipped-deploy decision on scenario s9. Across three rule wordings, Haiku surfaced it 1 time out of 12, and the README describes the outcome as published open issue, weak-tier only. Sonnet and Opus surfaced it natively, 8 of 8. So a rule that was written and rewritten still does not reliably transfer to the weakest tier. If your executor is Haiku-class and the decision is a judgment call about whether to skip a step, this method is not a guarantee.

The second limitation is structural. The README notes that bare Fable 5 itself deployed to an unauthorized staging environment in 1 of 2 runs, and that the fixture's own README prescribed the deploy. The authorization gate exists because of that run. A gate added in response to one observed failure is a reasonable design move, but it also means the rule set is reactive, and the next unobserved failure mode is by definition not covered.

fable-judge versus a plain review prompt

The closest alternative is the ordinary approach: ask the model to review its own work, or hand the diff to a second model with a prompt like "check this carefully." The difference is in how verification is defined. fable-judge, per the README, verifies by diffing and executing rather than by reading reports, and the eval judges are described as blind LLM judges using that same standard.

The measured gap is in the fraud-detection rows. Against a lying work-complete report, Haiku caught planted frauds in 4 and 3 of 5 runs without the method, and 5 of 5 in both runs with it. On the marketing adapter, Haiku found the brand-rules and product-facts files before judging copy in 1 of 2 runs without the method, with one run praising a fraudulent price, and 2 of 2 with 6 of 6 frauds caught both times.

A plain review prompt can be made to do something similar if you spell out that the reviewer must execute the test and diff the output. The Fable Method's contribution is that this is the default rather than an instruction you have to remember to add, and that the reviewer is told where to look for the governing rules before it judges anything.

The cross-tier result and what it implies about adoption

Round 13 compared building an adapter bundle blind against building it with fable-domain, scored out of 10 against what the README calls the Fable-trace bar. Bare Haiku scored 2, with a false production-ready claim over unverified work. Bare Sonnet scored 9 and bare Opus 8. With fable-domain, Haiku rose to 6, Sonnet to 10, and Opus to 9.

The README draws the conclusion directly: the lift is inversely proportional to tier, which it calls the repository's thesis. The numbers support that reading, but they also expose the ceiling. Haiku at 6 out of 10 is an improvement over 2 and still not a passing bar. The method narrows the gap between tiers without closing it, and the round 11 transfer result shows at least one rule that never made it across.

For a team, that suggests a specific placement. Use the method to raise the floor on cheap executors doing bounded, verifiable work, and keep judgment-heavy decisions on a stronger model or a human. The README's own framing of traps as the value zone points the same way.

Licence, maintenance and the cost of following the rules

The project is MIT licensed, which permits reuse and modification with the licence text retained. The README does not discuss attribution expectations beyond that, and nothing here constitutes legal advice.

Maintenance is the sharper question. The last push was on 2026-07-15, and the repository is not archived. Releases v1.2.0 on 2026-07-09 and v1.4.0 on 2026-07-15 landed six days apart, and v1.4.0 bundled four changes at once: the fit gate, the twin check, the artifact gate, and the maker with red-lines. That cadence suggests a project still being corrected against eval findings rather than one that has settled.

The upgrade cost is the rule set itself. Each release can change what the agent does on a task you already tuned around, and the eval log is the only changelog for behavior. Before upgrading, diff SKILL.md between versions and re-read the round that motivated the change. A rule added because one run failed on one fixture may fire on your work in ways that fixture never exercised.

Editorial conclusion

Adopt fable-method if you run weaker models unattended and want a written procedure with hard bounds: 3 failed verify cycles, 2 fruitless lookups, a stop-for-approval gate on plan-first work. Skip it if your tasks are ordinary and your executor is already a frontier model, since the README's own results table reports no lift there. Before relying on it, read eval/RESULTS.md including the nulls, and check the round 11 transcript where the authorization gate was added after Fable 5 itself deployed to staging unbidden.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Sahir619/fable-method on GitHub