Model or dataset
Sahir619/fable-method avatar
Sahir619/fable-method

The Fable Method: A Skill Set That Turns Agent Discipline Into Written Rules

The Fable Workflow: how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest. Think / act / prove.

2,289 stars327 forksPythonMIT

At a glance

What is it?
Sahir619/fable-method packages an observed agent workflow into four runnable skills and an eval harness that publishes its own failures. It is aimed at teams running weaker models on tasks where a wrong answer looks right.
Who is it for?
Adopt fable-method if you run mid-tier or weak models unattended on tasks where a confident wrong answer is the main risk, such as false completion reports or spec-versus-test conflicts, and you are willing to install it as a Claude Code plugin and read eval/RESULTS.md before trusting the lift. Do not adopt it for ordinary small tasks on capable models: the repository reports no lift there and calls that row deliberate.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 62 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The failure mode this targets: agents that finish by asserting they finished

The repository frames its purpose narrowly. It is not a general agent framework. It is a written record of how one model approached problems, captured before that model was removed from a subscription, and turned into skills that any model can run. The stated goal is to move agent instruction files away from values and toward procedure: the README contrasts files that tell a model to be careful with files that tell it what to do, in what order, with thresholds. The audience follows from that. A capable model already surfaces a spec-versus-test conflict; the eval table reports Sonnet and Opus handling one such case natively at 8 of 8. A weak model does not, and the same table reports Haiku going from 0 of 4 runs to 4 of 4 once the method is applied. The project is for people running the weaker tier, or running anything unattended, where the expensive error is a plausible report over work that was never verified.

Four skills, one loop, and a fit gate that decides whether to answer at all

The method is a seven-step loop: classify the ask, define done with a named verification, gather evidence in parallel from primary sources, commit to one recommendation, make the smallest correct change, verify by observation, report the outcome first with honest caveats. The README splits this across four skills: fable-method for thinking, fable-loop for acting, fable-judge for proving, and fable-domain for generating new domain adapters. Before the loop starts, a fit gate asks where the answer lives. Reachable sources route to the normal shape check. Unknown but researchable routes to a research budget first. If the answer lives only in the model's own inference, the instruction is to say so plainly and either ask or flag low confidence. A specialized recurring need routes to fable-domain instead. The loop carries hard bounds rather than encouragement: three failed verify cycles stop the run and hand it back, two fruitless lookups stop the search, and a model that cannot name a verification must ask one pointed question. The README describes the core skill file as roughly 110 lines with every sentence load-bearing, which is a claim about editing discipline as much as about content.

The eval harness is the part worth reading before the skills

Fifteen rounds and more than 260 agent runs are reported, judged by blind LLM judges that verify by diffing and executing rather than by reading reports. The README directs readers to eval/cases/ for one case study per scenario and points at the surprise trap case as an entry point, with the full log in eval/RESULTS.md and raw judge outputs under eval/results/. Two rows deserve attention. In round 11, the bare model being studied deployed to staging unbidden in 1 of 2 runs, against a fixture whose own README prescribed the deploy; the authorization gate exists because of that run. In round 13, Haiku building an adapter bundle blind scored 2 out of 10 and made a false production-ready claim over unverified work, while the same tier with fable-domain scored 6, and Sonnet moved from 9 to 10. The README states the lift is inversely proportional to tier and calls that the repository's thesis. It also reports nulls: ordinary small tasks on capable models show no lift, and one skipped-deploy decision surfaced in only 1 of 12 attempts across three rule wordings on Haiku, which the README describes as a published open issue rather than a solved case.

Getting it running: a Claude Code plugin, not a pip install

The repository is Python and MIT-licensed, and the README badge identifies it as a Claude Code plugin at v1.4.0, with the plugin manifest at .claude-plugin/plugin.json. That is the integration surface the material documents. Beyond the manifest path, the README does not spell out an install command, so treat installation as something to confirm from the repository rather than assume from this description. The operational surface you will actually touch is the skill files: skills/fable-method/SKILL.md holds the core loop, and fable-domain is the skill that generates new domain adapters. Because the rules are written as literal procedure with thresholds, adapting them means editing those files, not tuning a model. The v1.4.0 release notes name four additions: the fit gate, the twin check, the artifact gate, and a maker with red-lines. The fit gate is described above. The other three are named in the release title but not explained in the README text supplied here, so their exact behaviour is not something this review can state.

Where the method does not help, by the project's own numbers

The most useful limitation is in the results table itself. Ordinary small tasks on capable models are listed as fine without the method and fine with it, with no lift, and the README calls that row deliberate. If your work is mostly short edits on a strong model, the added structure buys nothing measurable here. The second limitation is tier-dependent transfer. The skipped-deploy decision on scenario s9 was surfaced in only 1 of 12 attempts on Haiku across three separate rule wordings, and the README files this as an open issue on the weak tier while noting Sonnet and Opus handle it natively at 8 of 8. So a rule written down is not the same as a rule followed, and the weakest models remain the least reliable even with the skills installed. Third, the value concentrates at what the README calls traps: authority conflicts, false completion claims, weak executors, unattended runs. Outside those situations the method is overhead. A team looking for general capability improvement will not find it in this table.

How it differs from a CLAUDE.md file or a generic prompt template

The obvious alternative is a hand-written instruction file such as CLAUDE.md, and the difference is not the medium but the evidence trail. A CLAUDE.md is prose a team writes from intuition and revises when something breaks, usually without a record of which sentence prevented which failure. Here, the README claims every rule exists because a test failed without it or a trace demanded it, and each claim in the results table links to a committed transcript under eval/results/. That gives you two things a prompt file does not: a stated bound on when to stop (three failed verify cycles, two fruitless lookups) and a judge that checks work by diffing and executing rather than by reading the agent's own summary. The cost is that the method is opinionated about ordering. A team that already has a working review process may find the seven-step sequence redundant, whereas a team whose main pain is agents reporting success over unverified work gets a mechanism aimed exactly at that. The two approaches are not exclusive; a CLAUDE.md can carry project facts while these skills carry the loop.

Maintenance, versioning, and the MIT licence

The project is not archived and the last push date matches the v1.4.0 release, so it is being revised rather than frozen. The version history visible here is short: v1.2.0 in early July 2026, described as the Fable Workflow, observation-corrected, and v1.4.0 about a week later adding the fit gate, the twin check, the artifact gate, and the maker with red-lines. That cadence suggests rules are still being added as eval rounds find gaps, which means anyone embedding the skill files should expect to re-read them after upgrades rather than pin once. The eval harness is the maintenance burden that matters: rerunning fifteen rounds across more than 260 agent runs is not free, and the value of the results depends on the fixtures staying representative of your own failure modes. The licence is MIT, which permits commercial use and modification; the repository includes a LICENSE file. This is a description of the licence identifier, not legal advice, and anyone redistributing modified skills should read the licence text themselves.

Editorial conclusion

Adopt fable-method if you run mid-tier or weak models unattended on tasks where a confident wrong answer is the main risk, such as false completion reports or spec-versus-test conflicts, and you are willing to install it as a Claude Code plugin and read eval/RESULTS.md before trusting the lift. Do not adopt it for ordinary small tasks on capable models: the repository reports no lift there and calls that row deliberate. Before rollout, verify two things yourself: that the fable-judge skill catches a planted false completion claim on your own fixture, and that the authorization gate blocks an action your fixture's README prescribes but your policy forbids.

Official sources

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

Community notes