mrtooher 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 withmodel: "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.