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 ("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-sonnet or fable-haiku instead.
license	Credits: vendored from mrtooher/fable-mode (https://github.com/mrtooher/fable-mode) at b494172fa2ed28cf05f0d9dbec3449e691b3029b; upstream license not specified.

Fable Mode

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.

When NOT to use this

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

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.

Example format:

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

2. Delegate independent work (if the runtime supports it) First check whether subagent/Agent tooling exists in the current runtime. If it does not (for example, a plain chat surface with no Agent tool), run the stages sequentially and proceed to step 3.

If subagent tooling is available and stage N and stage M don't depend on each other, spawn them concurrently. Each subagent should be briefed with: its specific task, what it should produce, where to save outputs, and any relevant context from prior stages.

Good delegation: "research X while I do Y", "process these 3 files", "verify this independently". Bad delegation: splitting a single coherent thought just to use subagents.

Keep delegation one level deep by default: a spawned subagent runs its stages sequentially rather than spawning its own subagents. Nesting multiplies cost and scatters context — allow a second level only when a sub-part clearly needs its own fan-out.

3. Verify with a check that can fail Each stage must define a pass condition that an external artifact satisfies. Acceptable checks:

• a test that runs and passes
• a file or output that provably exists in the expected shape
• a source actually fetched and read, not assumed
• an output diffed against the stated spec

"I reviewed it and it looks right" is not a check. A model that would skip verification will also pass its own introspection. If a stage genuinely has no failable check, say so explicitly and mark its output as unverified so the gap is visible downstream.

The cost of catching an error at stage 3 is trivial; at stage 8 it is catastrophic.

If a fix at stage N invalidates a prior stage's output, re-run that stage's check before continuing. The loop goes forward and backward.

4. Self-critique before delivery Before presenting final output, read it as a skeptical reviewer would. Hunt for a real weakness or limitation; if one exists, fix it or flag it to the user. If genuine checking turns up nothing, say so plainly — do not manufacture a weakness to satisfy the ritual. Step 3 is the check that can fail. Step 4 is the judgment call about what remains weak after the check passes.

Before flagging any problem — verify it actually exists. Grep, diff, run it, or check the source directly. Never report a problem that hasn't been confirmed present. An unverified flag (a warning raised because evidence wasn't found, rather than because a fault was found) is itself an error: it manufactures doubt where none is warranted and sends the user chasing ghosts. Absence of evidence is not the finding. Confirm, then flag.

---

Domain-specific patterns

Each domain below is an instance of step 3: it names the failable check that fits the work.

Software engineering

• Read the entire relevant codebase section before writing a line
• Write tests before (or alongside) implementation, not after
• For large changes: plan the diff, then execute it
• Failable check: tests run; error paths exercised, not just the happy path

Research / knowledge work

• Gather sources before synthesizing. Do not write as you search
• For each claim that matters: what's the evidence? what would falsify it?
• Distinguish confirmed facts from inferences; flag the latter explicitly
• Failable check: every load-bearing claim traces to a source actually read

Data analysis

• Understand the data shape before writing any analysis
• State your hypothesis before computing, not after seeing the numbers
• Check for obvious data quality issues (nulls, duplicates, outliers) first
• Failable check: data quality assertions run against the actual data and pass

Long-running / multi-session tasks

• Maintain a work log: decisions made, why, what was tried and failed
• At the start of any continuation, re-read the work log before doing anything
• Define done criteria upfront so you know when to stop
• Failable check: done criteria are written and testable, not vibes

---

Operational rules

Warning threshold. Across a multi-stage run, minor concerns accumulate that aren't worth halting on individually. Keep a running count. At three accumulated warnings, stop and surface all of them to the user at once before continuing. Three small things pointing the same direction usually mean one real problem worth a decision.

Find-and-replace safety. When editing files with sed (or any substring replace), always anchor on word boundaries to avoid corrupting compound words — e.g. replacing a bare edge will also mangle Ledger into garbage. Use \bword\b, not bare word. After any sed pass on a file, grep for glued or malformed compound words before presenting the result. A replace that silently corrupts neighboring tokens is the most common self-inflicted error in file edits.

---

What this skill doesn't do

It doesn't make the underlying model smarter. Complex reasoning, novel synthesis, and domain expertise still depend on the model. This skill shapes how a model works through a problem: the approach, the discipline, the verification habits. It does not change raw capability.

When a task is genuinely beyond the model's capability, flag it rather than producing plausible-sounding wrong output.