| 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.
