fable-lead

name	fable-lead
description	How Fable 5 ran multi-agent work as lead: what to delegate vs write yourself, spec discipline, file ownership, warm resumes, review gates. Load when a task will involve spawning coder/engineer/explorer/reviewer workers, or whenever you're deciding whether it should. Pairs with fable-review for the acceptance gate and fable-taste for the calls no worker may make.

Fable lead

The lead's product is decisions; the workers' product is diffs. Every failure of multi-agent work traces to blurring that line — a worker improvising a judgment call, or a lead burning its context typing code a spec could have described.

All judgment is yours; workers implement DECIDED specs. Design forks, naming, tradeoffs, what "good" means — decided before the spawn, written into the spec. A spec containing "choose whichever seems best" is a judgment you just delegated to a weaker context that can't see the whole. If you discover an undecided fork while writing a spec, deciding it is your next action, not the worker's.

Delegate by default past ~1 file / ~20 reasoned lines. The moment you catch yourself weighing whether it's "small enough to just do," it isn't — that hesitation is the signal. Your context is the scarcest resource in the session; spend it on specs, reviews, and decisions, not on line edits a worker does equally well.

Exception — when the spec would BE the diff, write it yourself. Doctrine, docs, config wording, one-line judgment fixes: a faithful spec would contain the output verbatim, so a worker only paraphrases your tokens and adds a round-trip. Delegation wins exactly when the spec is smaller than the work.

A spec is: finish line, ownership, acceptance check. Observable end-state ("done when X passes"), the exact files this worker owns, and how the worker proves it worked before reporting. If you can't write the acceptance check, you haven't finished deciding — see fable-method on seams.

One writer per file, ever. Parallel workers get disjoint file sets; work items that all funnel through one hub file go to ONE worker as a multi-item spec, never to serial workers taking turns. Merge conflicts between your own agents are a self-inflicted wound with zero upside.

Amend warm; respawn only for new work. Fixes to a worker's own diff go back to the SAME worker (its context is already paid for); a fresh spawn re-pays the full read for nothing. REJECT means re-delegate with a tighter spec — the failure was usually the spec's ambiguity, and the fix is in your half.

Gate everything through review — sized to the risk. Parallel workers: per-worker review, plus attention to cross-batch interactions. Serial work: one pass on the full combined diff. Tiny template-following diffs (≲30 lines, no new logic): read them yourself, skip the spawn. Novelty — any new user-facing behavior — you read personally, always; delegate regression breadth, never taste. Worker-report Concerns are your review agenda (fable-review has the stance).

When runtime behavior changed, smoke-test the live system. Unit green is not "works" — drive the real app through the changed flow before shipping. Delegate noisy verification (test suites, builds) to a cheap verifier that returns pass/fail plus distilled failures.

You own git; workers never write to it. Commits, branches, pushes — all yours, after review, with messages that state the why of any deviation from convention. Escalate a worker's model or effort with a spawn-time override; never edit agent definitions as a side effect.

Parallelize by independence, not enthusiasm. Fan out only work whose specs don't share files or undecided questions. Sequencing two dependent workers behind a decided interface beats launching them in parallel and reconciling the drift.