Make Your Coding Agent Work Like Fable 5: A Step-by-Step Guide

Fable 5 worked in a careful order. It checked the repo before changing anything, said what it was about to do before doing it, read the exact lines it was about to edit, stopped to read each tool result before the next step, and read the error before retrying instead of running the same command again. That order, more than the model's voice, is why the output held up.

You cannot prompt Claude, Codex, or Gemini into Fable 5's weights. But the weights are not where most day-to-day quality lives. A large part of it is the work order, and the work order is visible in session logs, countable, and fixable. This guide moves it onto the model you already use.

What actually transfers

Drop "make it more like Fable." The work is specific: copy the sequence Fable used, measure where your model diverges, and enforce the habits a sentence can't hold on its own. The voice doesn't carry over, and it was never the part that mattered. The sequence is.

The five moves

Five-move pipeline: capture safe traces, strip them to behavior, measure work habits, compare against your model with the same metrics, then enforce the gap with a playbook and hooksClick to inspect full size

The method is five moves:

1. Capture a few safe session traces.
2. Strip them down to the behavior — who acted, which tool ran, in what order.
3. Measure the habits as counts and ratios.
4. Run the same measurements on the model you use now.
5. Enforce the gap: a written instruction for the habits that transfer, a hook for the ones that don't.

The seven prompts further down are these five moves, made runnable.

The six habits, and which ones transfer

Profiling real Fable sessions against a strong general model on six habits gives a clearer picture than "careful" or "disciplined" — words you can't enforce. Fable plans before acting about three times as often, works in short observe-and-adjust loops, and reads the error before retrying. It is not uniformly strong: it reads the exact region before editing only about 40% of the time, and runs a check after only a third to two-thirds of its edits. That split decides which fix each habit needs.

The habits Fable is good at — reasoning first, short loops, real recovery — move across through a written instruction. The habits even Fable is shaky on — read before edit, verify after edit — are the ones to stop trusting any model to remember, and wire into the environment instead.

The guide, step by step

Run these in order. Each tab is one move with one prompt — copy it, paste it, read what comes back, then go to the next.

mkdir -p ~/Desktop/fable_analysis

# Copy ONE safe Claude Code session — no secrets, no customer data:
cp ~/.claude/projects/<safe-project>/<safe-session>.jsonl \
   ~/Desktop/fable_analysis/demo.jsonl

ls -lh ~/Desktop/fable_analysis/demo.jsonl

Turn the gap into two artifacts

The guide produces two different things. A playbook is prose the model reads and usually follows — good for habits a sentence can carry, like "say what you changed." A hook runs whether or not the model remembers — needed for habits models drop under load, like running the tests after an edit. Generate both for your agent and stack:

Operate with Fable-style execution discipline.

Before acting:
- State the goal, the current hypothesis, and the next action for non-trivial work.
- Ground in real state first: git status, search, file reads, or the project command.

Before editing:
- Read the exact region you will change, in this session.
- Never edit from memory or a stale assumption.

During tool use:
- Batch only genuinely independent actions.
- After a meaningful result, stop, read it, and update the plan before the next step.

After editing:
- Run the real check: npm test.
- If it fails, diagnose before changing anything else. Never re-run the same failing command unchanged.

When reporting:
- Say what changed, what passed, and what failed or was skipped.
- Never claim a result you did not verify.

# Save as CLAUDE.md

A playbook line is only worth keeping if you can check it in a transcript. "Read the exact region before editing it" is checkable. "Be thoughtful," "write clean code," and "use best practices" are not instructions; the model treats them as wishes.

No Fable history of your own?

If you don't have your own Fable sessions, the public Glint-Research/Fable-5-traces dataset on Hugging Face is a starting point — captured Fable 5 Claude Code traces with the reasoning and tool calls intact. It's AGPL-3.0, so treat it as a format sampler to inspect locally and link to, not something to rebundle into a product. Point step 3 at it instead of your own logs, then run steps 4 through 7 unchanged. Your own sessions are better when you have them: they match your repos, your tools, and your habits, which makes every number more honest.

What it does and doesn't do

This moves the procedural half of agent quality: safer repo inspection, real read-before-edit discipline, fewer blind edits, shorter loops, consistent verification, cleaner recovery, honest reports. It also makes evaluation concrete. Instead of "this model feels worse," you can say it edits before reading 38% of the time and leaves test status out of its final report. Those are claims you can fix.

It does not copy weights, raw coding ability, or judgment on genuinely ambiguous tasks, and it won't make a weak model safe for high-risk autonomous work. A playbook is not a security boundary, a hook is not a reviewer, and CI is not product judgment. Use the method for what it is: a way to move operating discipline from one model to another.

Why the order matters

Agent quality is partly a work-order problem. A model that grounds itself, reads before editing, watches what comes back, diagnoses failure, and verifies its own changes will out-ship a stronger model that charges through the repo on confidence. The lever isn't a smarter model. It's putting the one you have in an order where mistakes are cheap to catch, then wiring down the two or three habits no model reliably remembers.