fable-mode

# Fable Mode (v3) Decompose before acting, delegate to named agents, verify with checks that can fail, self-critique before delivery. The skill shapes procedure, not capability: benchmarked 2026-07 — on short graded tasks Opus/Sonnet score the same with or without it; the measured value shows on open-ended research (real sources vs. plausible fabrication) and on enforcing verification at lower tiers. ## When NOT to use this One obvious correct approach, fits in a single pass → do it directly. Staging a trivial task buries the answer under ceremony. ## v3 delegation rule — the load-bearing change Prose-level "you may spawn a worker" gets skipped: the model runs the task inline in the main thread. Delegation is therefore structural now: - If the fable agents are installed (`fable-orchestrator`, `fable-worker-sonnet`, `fable-worker-haiku`, `fable-verifier`), route large tasks through **@fable-orchestrator** — an Opus agent with no Write/Edit tool (fable-fable runs the same agent with `model: "fable"`; ladder is Haiku → Sonnet → Opus → Fable → user). It cannot produce artifacts itself; every artifact must come from a named worker, every deliverable can face a cold **@fable-verifier** pass. - If they are not installed, run the loop inline (below) on the current model — and say so, since inline mode loses the enforcement. ## Core loop (inline fallback; also what the agent definitions encode) **1. Stage map first.** Numbered stages, expected output each, one verifiable artifact per stage. Living document; at most two full replans per run — a third means requirements-level ambiguity, go back to the user. **2. Delegate by name where possible.** Sonnet-worker for reasoning stages, Haiku-worker for bulk mechanical stages, verifier for cold checks. Workers get: task, exact output path, context, named pass condition. Workers don't spawn workers. Cap concurrency. **3. Verify with a check that can fail.** A test that runs, a file in the expected shape, a source actually fetched, an output diffed against spec. "Looks right" is not a check. Name the exact command/file/comparison or mark the stage unverified. A fix at stage N re-runs the checks it invalidated. **4. Self-critique before delivery.** Skeptical read; fix or flag a real weakness; a clean pass stated plainly beats a manufactured caveat. Beyond capability → name what was attempted and where it failed. **5. Mandatory delivery gate: double-check.** Before presenting anything to the user, invoke the **double-check** skill on the finished deliverable (fresh checker panel; fixes any FAIL; attaches a verification summary; degrades to a cold self-check without the Agent tool). Not optional; never run twice on the same deliverable. ## Domain checks Software: touched files were opened; named test command passes; one error path shown. Research: every load-bearing claim maps to a source fetched this run; training-memory claims labeled. Data: shape printed first; quality assertions run with output; one subtotal recomputed. Documents: rendered file read back against spec line by line. Long-running: work log, testable done criteria, each continuation re-reads the log. ## Operational rules Live in the always-on **execution-guardrails** skill (verify-before-flag, warning threshold of three, word-boundary find-and-replace). They bind every model, every task, whether or not this loop runs.