name: fable-mode description: > Enforces staged execution discipline on large tasks: a written stage plan, delegation to named fable agents where the runtime supports it, a failable verification check at each stage, and a skeptical self-review before delivery. Trigger when the user explicitly asks ("do this thoroughly", "be systematic", "deep work mode") OR when the task objectively spans multiple files, multiple sources, or multiple sessions. Do NOT trigger on ordinary multi-step requests that a direct attempt handles fine. For a run pinned to a specific model, use fable-opus, fable-sonnet, or fable-haiku instead. Always-on guardrails (verify-before-flag, warning batching, sed safety) live in the companion execution-guardrails skill.

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

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.