/fable-mode

name: fable-mode
description: "Enforces staged execution discipline on large tasks: a written stage plan, parallel delegation 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 OR when the task objectively spans multiple files, sources, or sessions. Do NOT trigger on ordinary multi-step requests that a direct attempt handles fine (autonomous triggering only; explicit invocation always runs)."

Fable Mode

Family version: v6 (2026-10-10).

This skill encodes execution discipline for complex work: decompose before acting, delegate where the runtime allows, verify with checks that can fail, self-critique before delivery.

A note on what this is. The skill shapes the *procedure* a model follows. It does not change the model's underlying capability. Coherence across long tasks and genuine self-correction live in the weights, not in a prompt. On a model that already does these well, the skill reinforces good habits. On a weaker model, it imposes structure the model would otherwise skip, but it cannot lift the model's reasoning ceiling. Treat this as a checklist, not a capability transplant.

Invocation gate

When the user names this skill — a slash command, or "deep work mode" / "be systematic" in words — RUN IT. Do not weigh whether the task looks big enough. The user's explicit invocation IS the trigger; the cost call is theirs, not yours.

The "when NOT to use this" judgment below governs only autonomous triggering — this skill deciding on its own to fire. It never overrides an explicit request. If you think the loop is overkill for what was asked, run it anyway and say so afterward.

**Spawn authorization.** Some hosts allow subagents only when the user asks for them, and do not count words like "thorough" as asking (observed: the cloud runtime's Agent tool, 2026-10-10). In this skill family, spawning — stage workers, a fresh verifier, double-check's checker panel — is authorized only when the user invoked this skill or a sibling (fable-opus, fable-sonnet, double-check) by slash command or by name ("fable mode", "fable on opus", "double check this"). A wording-only trigger ("deep work mode", "be systematic", "thorough") or an autonomous trigger does not authorize spawning: run the loop inline on this thread and run double-check in its self-check mode. Say which mode ran. If the host refuses a spawn anyway, do that work inline and say so.

**Usage limit.** When the user reports usage at their threshold (default: weekly 50% or session 75%), check in with them before continuing. Unless they say otherwise, finish inline with double-check in self-check mode.

When NOT to use this (autonomous trigger only)

If a task has one obvious correct approach, fits in a single pass, and the user did not ask for this skill, do it directly and skip this loop. Staging a trivial task wastes effort and buries the answer under ceremony. On autonomous triggering, this loop earns its cost only when a one-shot attempt would plausibly miss something.

Calibrate to the model running it

The loop's value inverts with model strength. Opus is the frontier tier and every escalation path below resolves to it. The escalation ladder is: Haiku → Sonnet → Opus → back to the user. Apply the loop at the right intensity:

• **Frontier-tier (Opus).** Plans, verifies, and self-corrects natively. Do NOT narrate

the loop or write a formal stage map for tasks the model would handle cleanly anyway — that is ceremony. Apply only: (a) the failable-check standard from step 3 when producing artifacts, and (b) everything in the execution-guardrails skill. Write a full stage map only for genuinely multi-session or many-file work. Opus's characteristic gaps: self-review that trusts its own introspection, and scope growth mid-run — hold the external-artifact standard and the replan budget even when the plan feels obviously right.

• **Sonnet-tier.** Run the full loop. Sonnet plans decently but reliably skips step 3 —

the check that can fail — and substitutes "looks right" review. Enforce step 3 hardest.

• **Haiku-tier.** Run the full loop with tightened checks: every stage gets a failable

check, no stage may be marked unverified without naming what check was impossible and why. Haiku under time pressure skips verification entirely; the loop exists to prevent exactly that. Accept that the ceiling is unchanged — Haiku with a checklist is still Haiku. Escalate to Sonnet or Opus rather than looping when the task needs synthesis the checks can't substitute for.

If the model cannot tell which tier it is, assume Sonnet-tier and run the full loop.

Core Loop

The loop is constant across domains. Only the verification artifact in step 3 changes by domain (see Domain-specific patterns).

**1. Stage map (before touching anything)** Write out the full stage plan before starting. Number the stages. Include a brief expected output for each. This is how you avoid discovering at stage 7 that you made a wrong assumption at stage 2. Update the map when what you learn invalidates what you planned. The map is a living document, not a contract.

Each stage should produce one verifiable artifact. If a stage produces nothing checkable, merge it with the next.

**Replan budget.** A living document is not an excuse to churn. Allow at most two full replans per run. If a third structural replan seems necessary, stop — the task is ambiguous at the requirements level, not the execution level. Surface the ambiguity to the user and get a decision before burning more stages. Renumbering or splitting a single stage does not count as a replan; reordering or rewriting the map does.

Example format:

Stage 1: [Name] → [Expected output]
Stage 2: [Name] → [Expected output]
...

**2. Delegate independent work (if the runtime supports it and spawning is authorized)** First check two things: whether subagent/Agent tooling