The Fable Ladder

The one new idea: a loop is just "do this, again, on a trigger." You already know how to ask Claude to do a thing once. A loop makes it keep happening.

Every 5 minutes, Claude reads your dev log and reports errors. Intervals can be 5m, 30m, 2h, 1d. Keep the session open: /loop is session-scoped, so it stops when you quit and auto-expires after 7 days.

What you will notice is the point: it works, but it is dumb. It re-reads the whole log every time and re-reports the same errors, and it never just says "nothing new." That friction is exactly what Rung 2 fixes.

Upgrade to Rung 2: the loop is only as good as its prompt. Make the prompt do the thinking.

The one new idea: the prompt is the program. A loop runs its prompt over and over, so any vagueness compounds. Three properties turn a noisy loop into a clean one: bounded (only look at new work), specific (exact output shape), idempotent (safe to run again, with a real no-op when nothing changed).

Bounded: "only the NEW lines since your previous check" stops re-scanning. Stateful: "remember the last line number" gives the loop a memory. Specific: path:line short summary pins the output so it is parseable. Idempotent: "reply with exactly NOOP" means a quiet system produces quiet output.

The transferable rule: before you put any prompt in a loop, ask what it does on the run where nothing has changed. If the answer is "repeats itself," it is not loop-ready yet.

Upgrade to Rung 3: a sharp prompt still only runs on a trigger. Sometimes you want "keep going until this is actually true." That is a goal.

The one new idea: a loop knows how to repeat. A goal knows when to stop. /goal sets a completion condition and Claude keeps working across turns until that condition is true. After each turn a small fast model checks it; if it does not hold, Claude automatically takes another turn. The difference is "it ran" versus "it is done."

Claude grinds across as many turns as it takes until that exact condition holds, then stops. Keep loop and goal straight: a loop is an action on a trigger ("do this every 30 minutes"); a goal runs until a condition is met ("keep going until tests pass"). They compose.

Good conditions are verifiable: counts, exit states, presence of a file, a passing command. Weak conditions are vibes ("the code is clean," "the post is good"). Write conditions you could check yourself, because that is exactly what the goal-checker does.

Upgrade to Rung 4: a goal makes one session grind to done, but in your context, on your model. For big or repetitive work, hand it to a worker with its own context and its own cheaper model.

The one new idea: you can spawn a worker. A sub-agent runs with its own context window and its own model, does its job, and reports back. Two wins: your main session stays clean, and you pick the model the work deserves. Grindy, well-scoped work goes to a cheaper model.

Dispatch it by name from your main session: Use the test-writer agent to add tests for src/auth.ts, or mention it directly with @agent-test-writer.

The model is the lever. The frontmatter line model: sonnet is cost routing in one field. Aliases: sonnet, opus, haiku, fable. Resolution order, highest first: CLAUDE_CODE_SUBAGENT_MODEL, a per-invocation override, this frontmatter, your main session model. Route the grind to Sonnet/Haiku, keep the judgment on Opus or Fable.

Upgrade to Rung 5: one worker is useful. The magic is a team of workers a smart planner coordinates, all in parallel, with the planner checking each result.

The one new idea: stop choosing between "smart and expensive" and "cheap and fast." Run a dynamic workflow where Fable does the high-end thinking (plan and judge) and fans the heavy lifting out to Sonnet workers in parallel. You pay top-tier rates only for the few hard decisions; the volume runs cheap. This is everything from Rungs 1 to 4 composed.

The pattern in one breath: /model fable makes your session (the orchestrator) think with Fable. The workflow calls agent() for each step. Steps with no model override inherit the session model (Fable), so the planner and the judge run on Fable. Worker steps pass { model: 'sonnet' }, so the execution runs on a cheap workhorse, in parallel.

Run it: confirm claude --version is v2.1.170+ on a paid plan, /model fable, drop the script in your project, then ask Claude to run it, for example run the plan-fanout-verify workflow with request: "add input validation to every POST route in src/api and a test for each". Swap a worker to opus when a step needs more muscle.

Cross the chasm: you now have the whole pattern. Put a /goal around a session that launches this workflow and re-runs the failed items until they pass. Point the planner at your real backlog. The ladder ends here on purpose: the next move is yours to design.