fable-mode

What the source does

• FilesystemDeclared1 observation
• NetworkNone observedNo outbound calls in the source
• ShellDeclared1 observation
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass, no license.

fm = yaml.load(fm_text, Loader=_UniqueKeyLoader)  # noqa: S506 — SafeLoader subclass

Audit 0.4.1 · source sha b408dd144c3e · 20 Oct 2026Report an issue or request a re-scan

• Publishermrtooher GitHub userOwner of the repository this skill is read from
• Source foldermrtooher/fable-modeThe exact folder we audited
• LicenceNot declaredAs the repository states it
• Commit pinned for this verdictb408dd144c3eA new audit runs when the source changes
• Repository statusNot archivedLast push 8 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

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

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

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-20
   ✕BLOCK D 69 / 100

   first audit · source b408dd144c3e

Questions about fable-mode

• github.com/mrtooher/fable-mode — the audited source at commit b408dd144c3e and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology