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