Fable Mode

Benchmarks

This skill isn't in a benchmarked category yet. Set metadata.type in the frontmatter to activate scorecards.

Skill content

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