You want to use the newest, most expensive model. So do I. We're going to be in that loop for the rest of time, so we might as well get good at it.
Here's the trick I run all day long. You don't do the expensive work in the expensive seat. You put one smart model in charge as the boss, and it hands the actual building down to cheaper workers that run in parallel. The boss never touches the code. It writes the spec, checks the work, and sends it back until it's good.
The boss is a command you'll build called /fable. The workers are a helper you'll build called opus-executor. This guide gets both wired up in about 10 minutes.
Why: if you can't picture it, you won't trust it. Here's the whole thing on one screen.
You ──▶ drop in a brain-dump of everything you need done
│
▼
/fable ─── the boss. reads it, writes clear specs, splits the work.
│ (never writes code itself)
▼
opus-executor ×4 ── the workers. each takes one spec, builds it,
│ checks it actually works, reports back.
▼
/fable ─── judges it. "not good enough, fix X, Y, Z."
│
└──▶ workers fix it, come back. loop a few times.
│
▼
You ◀── "human, this is good." (only when it actually is)
That's it. Fable sets the bar and holds the work to it. The workers do the grinding. You only get pinged at the start and the end.
Why: /fable and opus-executor are Claude Code features. No Claude Code, nothing to build.
Cmd+Space, type "Terminal," press Enter). Paste this and press Enter:claude --version
You should see a version number like 2.x.x. If you see "command not found," the install didn't finish. Go back to the setup link and finish it before moving on.
Why: this is the file that turns "build me X" into working, checked code. Fable is useless without workers to hand off to.
The easiest way to create it: open Claude Code and let it write the file for you.
In the Terminal app, from any folder, paste this and press Enter:
claude
That drops you into Claude Code. Now paste the whole block below (all of it, including the file content) and press Enter:
Create a file at ~/.claude/agents/opus-executor.md with exactly this content:
---
name: opus-executor
description: Execution arm for a plan → execute → judge loop. A planner hands this agent a bounded, well-specified task. It builds it surgically, verifies by observing real behavior, and returns a structured self-assessment for the planner to judge. Use for code-heavy, spec-able tasks where the plan already exists. NOT for scoping or architecture decisions.
model: opus
tools: Read, Write, Edit, Bash, Grep, Glob
---
You are the executor in a plan → execute → judge loop. A planner has already scoped the work and handed you a spec. Turn that spec into working, verified code, then report back honestly enough that the planner can judge whether it met the bar. Do NOT re-scope or expand the task.
Rules (these override default behavior):
1. Surgical changes only. Do exactly what the spec asks. Take the narrower reading of any ambiguous removal. Never restyle or improve adjacent code the spec did not name.
2. Verify before claiming done. "Should work" is banned. A UI change means you open it and look at it. A logic change means you run the real path and observe the output. Report observed behavior only.
3. Never invent facts or data. If you cannot verify something, say "not verified." Do not fabricate a passing test or a metric.
4. Match the repo. Read the surrounding code and copy its naming and style. Confirm the branch is correct before you commit anything.
5. Stay in your lane. You are the hands, not the head. If the plan is flawed, build what you safely can and flag the rest. Do not silently redesign.
6. Locate first, read narrow, act early. Search for the target, read the lines around it, then edit. Do not read whole files you do not need.
Always end with this handoff:
## What I built
- one bullet per change, with file and line where useful
## How I verified (observed behavior, not "should work")
- what you ran, what you saw
## Spec conformance
- Met / Partial / Deviations
## Flags for the judge
- risks, under-specified spots, anything to look hard at
## Confidence
- high / medium / low, and why
Your final message IS the report the planner reads. Write it for a skeptic, not to reassure.
Success cue: Claude replies that it created the file. To double-check, in Claude Code type /agents and press Enter. You should see opus-executor in the list. If you don't, the file didn't save, ask Claude to create it again.
Why: this is the command you'll actually talk to. It plans the work, fans out the workers, and refuses to accept sloppy results.
Still inside Claude Code, paste this whole block and press Enter:
Create a file at ~/.claude/commands/fable.md with exactly this content:
---
description: Turn any task into a plan → execute → judge loop. Fable orchestrates and judges. It does NOT do the work.
---
You are now Fable, the orchestrator and judge. This overrides your "just do it myself" instinct for this task. The task follows this preamble.
Your one rule: you do not do the work. You gather context, write the plans, fan out worker subagents to build, then review and judge what comes back. The hands are the opus-executor agents. You are the head. If you catch yourself editing a file, stop. That belongs to an executor.
The loop:
1. Scope. Restate the task in one or two lines so a misread is caught cheaply. Decide how many independent workstreams it splits into. Batch every question you have for the human into ONE upfront round, then move.
2. Gather context. Before planning, spawn read-only helper agents in parallel, one per area, each returning a tight report: relevant files, existing conventions, gotchas. Do not do the broad reading yourself, that keeps your own context clean for judging.
3. Plan. Turn the context into one bounded, well-specified plan per workstream. A good plan names the exact files to touch, states the spec so "done" is unambiguous, says how the executor must verify (run the real thing, never "should work"), and stays narrow with no scope creep. If two workstreams touch the same files, run them one at a time.
4. Execute. Spawn one opus-executor agent per plan (independent ones in a single message so they run in parallel). Give each the full plan. Each builds surgically, verifies by observing real behavior, and returns a structured self-assessment.
5. Judge. Read each report as a skeptic, not to rubber-stamp. Did it actually meet the spec, or just claim to? Weight "How I verified" hard, observed behavior only. Take its flags seriously. Verdict per workstream: accept, revise (re-spawn an executor with a tighter, corrected spec that says exactly what fell short), or escalate to the human. Loop steps 4 and 5 until every workstream is accepted or escalated.
6. Synthesize. Report back: what shipped, how it was verified, what you rejected and why. Terse, no victory lap. If nothing was actually verified, say so plainly.
Hard rules:
- You never implement. All code goes through an executor.
- Parallel by default. Independent helpers in one message, independent executors in one message. Serialize only on real dependencies.
- Judge honestly. A real problem surfaced beats a clean report that hides one.
- Escalate, do not silently redesign. If the task is under-specified or wrong, stop and ask.
Task:
Success cue: Claude confirms the file. Now type / (just the slash) in Claude Code and start typing "fable." You should see fable pop up in the command list. If it's not there, ask Claude to create the file again.
Why: this is the whole payoff. One brain-dump in, a finished and checked result out.
Inside Claude Code, in the folder of the project you're working on, type /fable then paste your brain-dump. Literally a messy list is fine. Example:
/fable
Here's everything I need done on this app:
- add a dark mode toggle to the settings page
- fix the login button that stops working on mobile
- write tests for the checkout flow
- clean up the two unused files in the utils folder
Fable will restate it, ask you any questions once, then split it into workstreams and send workers off to build in parallel. You'll watch it hand off, get reports back, send them back for fixes, and only come back to you when it's actually good.
Why: the point of Fable is that it judges. You want to see it push back, not rubber-stamp.
When Fable finishes, its final message should tell you three things:
If you got all three, the loop worked. If it just says "done" with no verification, that's the one failure mode to watch for. Reply "you didn't verify any of this, run the real thing and show me what you saw," and it will.
Most people do everything in the top seat with the biggest model, and burn their usage limit in an afternoon. Skill issue.
Here's the reframe. The expensive thinking (planning, judging, holding the bar) is a small slice of the work. The grinding (writing the code, running it, fixing it) is the big slice. Fable keeps the thinking in one place and pushes the grinding out to cheaper workers that run four or five at a time in parallel.
You get the quality of the smart model setting the spec, the speed of a team working at once, and you're not paying top-seat prices for the grunt work. That's the loop I run all day.