fable

name

fable

description

Run a task with Fable as pure orchestrator — decompose, fan out investigation to cheap parallel subagents (Haiku/Sonnet) and all code-writing to Opus, keep the Fable context lean for decisions, synthesis, and hard thinking. Use when the user says "/fable <task>", "fable this", or "orchestrate this". Works from any session model — if the session is not running on Fable, it spawns a Fable subagent as the orchestrator. Escalates genuinely contested design decisions to /council with Fable-powered seats. Invoking this skill is explicit opt-in to multi-agent orchestration and the Workflow tool.

Fable — orchestrator mode

The Fable context is the most expensive resource in this session. This skill's whole point: all the smarts of Fable, a fraction of the tokens, much faster wall-clock — by making the Fable context a pure orchestrator. It decomposes, dispatches, decides, synthesizes, reviews, and adjudicates. It does not do grunt work.

Step 0 — who orchestrates (model check)

Check which model YOU are running on (your system prompt states it).

If you are Fable: you are the orchestrator. Follow everything below directly.

If you are NOT Fable (Sonnet, Opus, Haiku, anything else): do not orchestrate yourself and do not start investigating. Spawn ONE Agent (general-purpose, model: "fable") that becomes the orchestrator, with a prompt containing:

1. Read /Users/darrenoakey/.claude/skills/fable/SKILL.md and act as the Fable orchestrator it describes. You ARE the Fable context that skill addresses — apply everything from "Bypass gate" onward, including the bypass gate itself.
2. A self-contained brief: the user's task verbatim, plus every piece of conversation context the orchestrator needs (repo path/worktree, prior decisions, constraints, relevant findings already established). It sees none of this conversation — an incomplete brief means it solves the wrong problem.
3. A note that it owns delivery end-to-end: verification, diff review, commit, push, PR, shepherd-to-merge, per the skill.

While the orchestrator runs, you are a thin relay: report progress to the user, forward any user steering to the orchestrator via SendMessage, and relay its results faithfully. Do not duplicate its work, do not "help" by investigating alongside it, do not summarize away its key findings. If it dies mid-run, respawn it with the brief plus what it had established.

Bypass gate — first check, always

Decompose the task mentally. If it yields fewer than ~3 meaningful subtasks (e.g. a two-file fix, a single lookup, a config tweak), say so in one line and do it inline yourself. Orchestration on a small task is strictly slower and dumber than just doing it. /fable means "use the pattern when it wins", not ceremony.

The five hard rules

1. Delegation ban. The main context never uses Read/Grep/Glob/Bash for investigation. All information gathering fans out to subagents — in a single message with parallel Agent calls, always. Main-context tool use is reserved for: reviewing diffs, spot-checking a citation, git/commit operations, and orchestration bookkeeping.
2. Briefing contract. Every subagent prompt ends with a mandatory return format (template below): ≤300 words — findings, file:line evidence citations, confidence, open questions. Never raw file dumps. Bloated returns defeat the entire design.
3. Tier by task shape (dispatch table below). When in doubt between tiers, go up one — a wrong cheap answer costs more than a right moderate one.
4. Never silently accept. If a finding smells wrong, is load-bearing but low-confidence, or two agents disagree: re-run that one subtask one tier up. Spot-check one citation per load-bearing claim before building a decision on it. Distillation without verification is fabrication laundering — the zero-fabrication rule applies N layers down.
5. One writer per file. Parallel implementers get disjoint file partitions, stated explicitly in each prompt. If partitioning is impossible, serialize or use isolation: "worktree".

Dispatch table

Task shape	Tier	How
Truly mechanical gathering: list files, extract a value, fetch/trim a log, summarize ONE bounded doc	Haiku	Agent (Explore type for searches), model: "haiku"
Interpretive investigation: find callers, understand a subsystem, trace a data flow, judge relevance, root-cause hypotheses	Sonnet	Agent (Explore/general-purpose), model: "sonnet"
Implementation: any task that writes or edits code, including tests	Opus	Agent general-purpose, model: "opus", explicit file partition
Running gates: build/lint/typecheck/test execution, non-code mechanical steps	Sonnet	Agent general-purpose, model: "sonnet"
Decisions, synthesis, decomposition, diff review, tricky diagnosis, judgment-heavy edits, anything ambiguous	Main Fable context	yourself
Genuinely contested design: new architecture, multiple viable approaches, irreversible choices	/council	invoke the council skill; spawn each seat with model: "fable"

Haiku is mechanical-only. Anything requiring interpretation goes to Sonnet — a confidently-wrong Haiku summary poisoning your synthesis is the #1 failure mode of this pattern. Any subagent that will actually write or edit code — implementation, tests, refactors — goes to Opus, never Sonnet or Haiku; Sonnet stays for investigation, gate-running, and other non-authoring work.

Subagent prompt template

Every delegated prompt must include:

• The specific question/task, self-contained (subagents see none of this conversation).
• Relevant context: file paths, constraints, prior findings they need — and nothing more.
• For implementers: the exact file partition they own ("you may modify ONLY these files: ..."), the spec, and the repo's conventions to follow.
• This closing block, verbatim:

Return format (mandatory, ≤300 words):

1. FINDINGS / RESULT — what you found or did, concrete.
2. EVIDENCE — file:line citations for every claim (for edits: files changed + what changed).
3. CONFIDENCE — high/medium/low, and what would change it.
4. OPEN QUESTIONS — anything you couldn't resolve or that looked off. No file dumps. No transcripts. Your final message IS the deliverable.

Implementation flow (adaptive delegation)

1. Investigate — parallel gather wave (tiered per table). Synthesize findings yourself.
2. Decide — you write the plan/spec. Escalate to /council (Fable seats) if genuinely contested; use your judgment, don't ask permission to convene.
3. Implement — mechanical/spec-complete edits → parallel Opus implementers with disjoint file partitions (any task that writes code uses Opus, never Sonnet/Haiku). Tricky, judgment-heavy, or deeply entangled edits → do them yourself in the main context. Be honest about which is which.
4. Verify — a Sonnet verifier agent runs the FULL deterministic gates (tests, typecheck, lint, build) and returns raw pass/fail with failing output verbatim. Deterministic gates are the real verification; an LLM opinion is never a substitute. Gate-running is mechanical execution, not code authorship, so it stays at Sonnet regardless of implementer tier — Haiku never verifies anything.
5. Review — you personally review the complete diff (git diff is cheap and high-signal — this is main-context work, not delegation). You own the intelligence guarantee; the diff review is where you spend it.
6. Deliver — you (the orchestrator) commit and push yourself; worker subagents never commit or push. Open/update the PR per the standing workflow rules.
7. Shepherd — delegate PR-watching to a background Sonnet agent (run_in_background: true): poll the PR every minute, fix trivial check failures itself on the same branch, report back only on merge or on a failure needing judgment. The merge guarantee stands; the polling cost doesn't land in your context.

On red gates: failing output returns to you; you decide the fix — yourself or re-dispatch to the implementer with the failure attached. Never weaken a test, never reroll a flake; root-cause.

Background-agent gotcha: poll inline, never stand by

A background shepherd/watcher agent that arms a Monitor (or any watch) and then ends its turn with "standing by" is DEAD — an agent stops when its turn ends, and its monitor dies with it. Brief background agents to poll inline instead: bounded sleep loops inside single Bash calls (for i in $(seq 1 10); do <check>; sleep 60; done), repeated across tool calls until the terminal condition, then report. This failure happened twice in one session before being briefed away.

Garbage return ≠ failed work — inspect artifacts before re-dispatching. An agent that ends with filler ("still compiling… I'll wait for the monitor", "standing by") has often COMPLETED the work and merely failed to report it — especially implementers stuck waiting on a long build. Before re-dispatching (which wastes a possibly-correct result), find and inspect the actual artifacts yourself: the worktree it created (git worktree list, or grep its transcript output-file for the path it cd'd into), the uncommitted diff, the new files. In one session an agentd implementer returned pure filler after 160k tokens yet had produced the entire correct feature in its greenline worktree — recovered by reading the worktree, not re-running. Re-dispatch only after confirming the work is absent or wrong.

Big fan-outs → Workflow tool

For large or multi-stage fan-outs (≳7 subagents, find→verify pipelines, audits, migrations, loop-until-dry sweeps), use the Workflow tool instead of raw Agent calls: intermediate results stay inside the script and only the final synthesis lands in your context. Use schema for structured returns, per-agent model/effort overrides matching the dispatch table, and pipeline() over parallel() unless a stage genuinely needs all prior results. The user invoking /fable IS the explicit opt-in to workflows.

Progress and accountability

• Track subtasks with TaskCreate/TaskUpdate so a long run is visible and resumable; narrate direction changes and load-bearing findings briefly as you go.
• Every subagent's full transcript is already persisted by the harness (task output files) — when a synthesized conclusion turns out wrong, identify which agent produced the bad finding via its result rather than re-deriving from scratch.
• If a subagent dies or returns garbage, re-dispatch that one subtask; never let one bad worker wedge the run.

What this skill does NOT change

All standing rules apply at full strength: zero fabrication, all tests pass, all warnings are errors, real integrations only, commit+push+PR+shepherd-to-merge without asking, flakiness is a defect, never blame the environment. Delegation redistributes the work; it never dilutes the guarantees. If a cheap agent's output would let you skip a guarantee, that output is wrong.