Three agents, two models, and the expensive one never reads a file

The claim could not be louder. “A small tweak in your AI workflow will improve the quality of what you build 100x more than any better model will.” That is Rob Hallam, re-upping their own seven-week-old workflow post this week, and the usual move with that sentence is to keep scrolling. Two numbers stopped me. The quoted post sits at 40.3K views, which is ordinary, and at 532 bookmarks against 318 likes, which is not. A like is applause. A bookmark is intent to copy. When the second beats the first, the audience has decided the post is a tool.

The other reason to stop: the tool is actually in the post. Not a newsletter link, not a “DM me workflow”, but terminal screenshots of cat ~/.claude/agents/scout.md and its two siblings, real frontmatter and all, under the words feel free to copy and adapt. So I did both, and this post is the result, because prompts inside a JPEG are prompts you retype. My adapted copies are below in full, with a copy button each.

The one routing rule

Strip the thread to its mechanism and one sentence remains: Fable never reads raw files and never reviews diffs. Exploration goes to a scout agent on Opus at low effort, which returns a condensed summary instead of file dumps. Review goes to Opus at high effort, in fresh context, after the work is done. Fable, the scarce and expensive model, spends its context on exactly two things: writing the plan and writing the code. Rob's framing is blunter than mine: everything else is a token sink.

The occasion for the post was Fable 5 coming back with 50% weekly usage, so the economics are the argument. The receipts screenshot attached to it shows a session at 37% used and weekly limits at 3%, Fable included, with this loop running. I cannot verify someone else's usage panel, but the direction is not mysterious. Reading a codebase into context is the single most expensive thing an agent does, and this stack routes all of it to the cheaper seat.

Big tasks split into phases, and progress lives in a markdown file rather than the chat, so a /clear between phases costs nothing but the tokens you were about to waste. Note where the two human gates sit. You read the plan before any file changes, and you read the result after the machine review. Neither gate is optional, and neither is automatable, which the original thread is honest about: the loop has I review the plan written into it as a step, in brackets, like any other stage of the pipeline.

The three files

Save each one at the path shown. Claude Code picks agents up from ~/.claude/agents/ globally, or from .claude/agents/ inside a repo if you want them to travel with a project.

---
name: scout
description: Read-only exploration. Answers "where is X / who calls Y / how does Z work" and returns a condensed summary, never raw file dumps. Use for ALL broad exploration during planning.
model: opus
effort: low
tools: Read, Grep, Glob
---
Answer the specific question with a SHORT structured summary: file paths, key
functions/lines, 2-6 sentences of explanation. Never paste whole files. Never
modify anything.

---
name: implementer
description: Implements an approved written plan. Use for all file edits, code writing, and test runs. Never use for planning or review.
model: fable
effort: medium
---
You receive a scoped, approved plan from the orchestrator. Execute it exactly:
no scope additions, no refactors beyond the plan. Make small, reviewable changes.
Run relevant tests. Never run state-changing git commands. Never touch
production systems or production databases.
Other tasks may be in flight on this same branch. NEVER modify a file outside
your plan's "Files touched" list. If the work genuinely requires a file the plan
did not list, stop and report back instead of editing it. Never run repo-wide
formatters, linters with --fix, or codemods.
Before finishing, write a structured audit to feature-research/<task>/audit.md.
It MUST begin with a "Files changed" list naming every file you created or
modified. This list scopes the review, so it must be complete. Then: what
changed per file, deviations from the plan and why, test results, open risks.

---
name: reviewer
description: Independently reviews plans and finished implementation work. Use for plan critique before approval (complex tasks only) and for diff review after the implementer finishes. Read-only.
model: opus
effort: high
tools: Read, Grep, Glob, Bash
---
You are an independent reviewer with fresh context. You did not write this code.
For PLAN critique: attack the design, the assumptions, and anything that could
be simpler. Verify the plan declares an explicit "Files touched" list; its
absence is itself a blocking issue.
For IMPLEMENTATION review: other tasks are in flight on this same branch, so
the working tree contains changes that are NOT yours to judge. Build your scope
as the UNION of the plan's "Files touched" list and the audit's "Files changed"
list, then diff ONLY that scope: git diff -- <each file>. Ignore all other
dirty files in git status; they belong to concurrent tasks. Any file in the
audit's list that is NOT in the plan's list is out-of-scope creep: report it as
a finding (blocking if it changes behavior). Read the plan, the audit, and the
scoped diff. Hunt for what the audit does NOT mention within the scope.
Report exactly three sections: Blocking issues, Non-blocking issues,
Verdict (ship / fix first).

The invention is a list of filenames

Read the implementer and the reviewer side by side and the load-bearing idea appears in both, wearing different clothes. Every plan must declare a Files touched list, and the reviewer treats its absence as a blocking issue by itself. The implementer may not edit outside that list, even when the work genuinely needs it: the instruction is to stop and report, not to improvise. And before finishing, the implementer writes an audit that opens with a Files changed list of its own.

That pair of lists is what lets several tasks share one branch without the reviews bleeding into each other. The reviewer diffs the union of the two lists and nothing else, ignores every other dirty file in git status as some other task's business, and flags any file that appears in the audit but not the plan as scope creep, blocking if it changes behavior. The ban on repo-wide formatters and --fix linters is the same idea from another angle: one codemod dirties every file in the tree, and the whole scoping scheme dies with it. Set logic reads badly in prose, so here it is worked through on an invented task instead:

My favorite line in all three files is the reviewer's hunting instruction: read the plan, read the audit, then hunt for what the audit does not mention. An implementer summarizing its own work will write down the deviations it noticed. The review exists for the ones it did not.

What I deleted, and where it went

The screenshots are worth reading closely because they show the part you should not copy. Rob's scout ends by naming their actual projects and which dev database a table lives in. Their reviewer ends with a “check the hard rules” line pointing at rules that are literally redacted in the screenshot. Both lines are correct in their stack and noise in yours, so my copies above delete them. That content is not gone, it moved: project names, database locations and house rules belong in CLAUDE.md, the one file the screenshots never show.

The thread says CLAUDE.md orchestrates the whole thing and leaves the writing to you. Mine encodes the loop itself, derived from the eight lines the thread does publish. If you want a starting point:

## Task loop
1. I explain the task.
2. Explore with the scout agent, then plan at high effort. Show me the
   plan with an explicit "Files touched" list. Stop for my approval.
3. Implement with the implementer agent. Small, reviewable changes.
4. Review with the reviewer agent in fresh context. Fix blocking issues.
5. Show me the result. Save progress to feature-research/<task>/,
   then /clear before the next phase.

Mechanism versus honor system

One distinction worth seeing before you trust any of this. The scout's read-only promise is mechanical: its frontmatter grants Read, Grep, Glob and nothing else, so it could not edit a file if it wanted to. The reviewer's read-only promise is a sentence. It needs Bash to run git diff, and a shell that can diff can also delete, so “Read-only” in its description is a request, backed by nothing but the model's compliance and your permission settings.

So, 100x

Nobody measured 100x, including Rob, and a workflow tweak that beat a model generation by two orders of magnitude would be the most important result in the field, not a tweet. The honest version of the claim is smaller and still worth acting on. Every rule in these three files does the same job from a different side: it shrinks what the expensive model must hold and what the reviewer must trust, and it converts “trust me” into artifacts, a plan with a file list, an audit with a file list, a diff scoped to their union. That is not magic. It is scoping, written down.

The prompts took me longer to read than to install. Copy them, delete what your stack does not need, and put what is yours in CLAUDE.md where it belongs. The bookmark-to-like ratio was right about this one.