Tale Mode

Anthropic pulled the plug on Fable. Tale Mode was made by Fable to get Opus to act like Fable.

Not smarter — more disciplined. A drop-in plugin for Claude Code and OpenAI Codex that makes
any Claude work like a careful senior engineer: verify the real code instead of trusting memory,
put a source on every decision, run an independent adversarial review before it says "done," and
keep durable notes. It also ships a self-armed autonomous loop that keeps working until a real
check passes, and makes plan-mode investigation dialog-free (a fail-closed hook auto-approves
provably read-only shell — plan mode only, so you approve the plan, not fifty grep prompts).
Everything is right-sized, so a typo fix stays a typo fix.

The model got pulled; the method didn't.

Contents: Quick start · Problem · How it works · Examples · Use it · Autonomous loop · What's different · Install · Security & trust · Tuning · Does it work? · What's in the box · Managing / removing · Contributing

Quick start

/plugin marketplace add alicicek/tale-mode
/plugin install tale-mode@tale-mode

Restart Claude Code (so it loads), then just ask:

tale mode — refactor the auth middleware and prove it still blocks expired tokens

That's it. It picks how much process the task deserves, plans, verifies against the real
code, and tells you what it couldn't check. For bigger work, reach for the
/tale-mode:plan-phase → /tale-mode:kickoff-phase pipeline. Requires
Claude Code ≥ v2.1.154 (the deterministic kickoff auto-arm needs ≥ v2.1.195,
where it was verified; on older builds the marker simply never fires and the loop
degrades gracefully to agent-armed goals).

The problem it targets

Strong models, under time pressure, predictably cut the same corners:

• act before understanding; one-shot a multi-step task
• trust their own summary of a file instead of re-reading it (stale claims, wrong
  line numbers, invented APIs)
• agree too readily and inscribe constraints nobody asked for
• review their own work — and miss the framing error they're inside
• drift on long tasks; forget earlier decisions
• declare "done" from the diff without running anything
• either over-engineer trivia or take shortcuts on the hard part

Tale Mode is a checklist-as-skill that targets each of these.

How it works

Three layers, built on one observation: instructions can be ignored by a rushing model,
but hooks can't. Words drift; hooks don't.

A · INSTRUCTIONS   the method the model reads      skill · phase commands · output style
B · ENFORCEMENT    deterministic bash hooks        session-start · phase marker · plan-mode read-only approve · the Stop-hook loop
C · REVIEW         eyes that aren't the author's   plan-reviewer agent · optional governor

Layer A teaches the discipline. Layer B enforces the parts that can be enforced — the
core rules injected into every session, and a turn that cannot end until a real check
passes. Layer C exists because a model fixes a bug instantly in someone else's code yet
misses the same bug in its own — so the reviewer is a fresh context, ideally a different
model. (Full walkthrough: docs/ARCHITECTURE.md.)

Within Layer A, a right-size throttle decides how much process a task earns (and, for
big work, how many phases to split it into) — so trivial work stays fast. Above that
floor it runs an 8-step loop:

The three tiers the throttle picks from:

• 🟢 Trivial — a typo, a rename, a one-liner: just do it. No ceremony.
• 🟡 Substantial — multi-file but reversible, no auth/money/data: the light loop.
• 🔴 High-stakes — auth / money / data / security, or hard to undo: the full loop,
  including the independent reviewer and durable notes.

Examples

Same trigger, different amount of process — Tale Mode right-sizes to the task.

🟢 Trivial — it stays out of your way

tale mode — fix the typo in the pricing heading

Recognizes it's trivial and just does it: no staged plan, no sub-agents, no
review. (Ceremony on a one-liner is its own failure mode.)

🟡 Substantial — the light loop (multi-file, reversible, no auth/money/data)

tale mode — migrate the marketing pages to the new framework

Maps the work, verifies its claims against the real files (re-reads them
instead of trusting memory), self-critiques, and flags anything it couldn't
check. Skips the heavyweight reviewer.

🔴 High-stakes — the full loop (auth / money / data / security, or hard to undo)

tale mode — implement Phase 2 of PLAN.md, only that phase

Re-verifies the plan against the actual code, interviews you on genuine forks,
works on a dedicated branch, proves it by running it — and for cross-browser
UI, checks a real WebKit/Safari render, not just Chromium — then runs an
independent reviewer before you ship, and updates the plan file when done.

🔴 Where the independent reviewer earns its keep — money / security

tale mode — change how the payment webhook verifies signatures

Because it touches money, it spawns a separate reviewer that reads the payment
code independently and hunts the traps self-review misses — e.g. consuming the
request body before verifying the signature, or an idempotency/race hole —
before the change ships.

🔍 Debugging — don't trust the happy path

tale mode — users say the page looks broken on iPhone; find out why

Reproduces against ground truth — a real Safari/WebKit render, not just Chromium
devtools — reads the actually-served files, and won't call it "fixed" off a clean
diff. (The discipline that catches cross-browser bugs in one pass instead of five.)

Use it

Three separate things turn it on — don't confuse them:

• The discipline (the skill) — say "tale mode" or "tale on", or it
  self-activates on complex multi-step work. This is the everyday mode: plan → verify →
  review → receipts. It's soft — the model loads the skill when the work matches.
• The phase commands (explicit) — /tale-mode:plan-phase and
  /tale-mode:kickoff-phase, for big multi-phase features (below). You type these.
• The autonomous loop (the hooks) — runs by itself; see Autonomous loop.
  You don't trigger it — the agent arms a goal-file and a Stop hook keeps it going.

Slash commands (namespaced under the plugin):

• /tale-mode:plan-phase <task> — plan to the full bar (verify-against-code, receipts,
  independent review, runnable gates) before any code. Large features come back
  decomposed into independently-shippable phases, each sized for one session.
• /tale-mode:kickoff-phase <plan-file> <phase> — implement one phase of a larger plan in
  a fresh session. Runs under plan mode: re-verifies the plan against the
  current code, interviews you, and waits for your approval before writing anything.
  The investigation itself stays fluid — provably read-only commands (ls, grep,
  git log, …) are auto-approved in plan mode by a fail-closed hook, so the one
  approval you give is the plan (details + kill switch in
  Security & trust).

The pipeline — one phase per session

Big features are built one phase at a time, each in its own session, so the working
context stays lean (a long session re-reads its whole window every turn):

/tale-mode:plan-phase <big feature>          → phased plan on disk (Phase 1..N), approved
   /clear  → fresh session
/tale-mode:kickoff-phase plan.md "Phase 1"   → plan mode → you approve → build → PR → stop
   /clear  → fresh session
/tale-mode:kickoff-phase plan.md "Phase 2"   → …

The plan file on disk is the durable hand-off between sessions; /clear between
phases keeps each one fast. For a small, single-session task, skip the pipeline and
just use /tale-mode:plan-phase (or a trigger).

Optional deterministic gates (run typecheck/lint automatically after edits, so
"green before you continue" is enforced by the harness, not the model's memory):
see docs/HOOKS.md.

Autonomous loop

Claude Code's /goal and /loop are user-only — you type them. Tale Mode ships a
loop the agent starts itself: it writes a goal-file (a success condition + a
deterministic check command), and a bundled Stop hook refuses to let the turn end
until that check passes — so it grinds a real task to green without you re-prompting each
step. It's live the moment the plugin is installed — the hook ships inside the
plugin; there's nothing to wire up.

// .claude/active-goal.json — the agent writes this at the start of a hard, verifiable task
{ "goal": "the auth E2E prints PASSED",
  "check": "npm test -- auth | grep -q PASSED",
  "rounds": 0, "max_rounds": 25, "needs_user": null }

• Layer 1 — the loop (hooks/stop-goal-loop.sh, free bash): check fails → the turn is
  blocked with the foundation-first / two-strike disciplines injected; check passes → the
  goal clears. It can't run forever (max_rounds + a fail-open if it can't persist state),
  and it pauses for you (needs_user) when it hits something only you can do — a secret,
  a deploy, a go/no-go — instead of grinding the impossible. Silent on any normal
  (non-phase, clean) turn. When armed, it appends one JSONL verdict line per round to a local
  .claude/tale-mode.log audit trail (disable with TALE_VERDICT_LOG=/dev/null).
  164 checks (56 cases) cover the fail/pass/pause/edge/log paths (incl. the committed-config trust/dirty/precedence, cross-platform cwd-root, pending-marker adoption, no-progress, and multi-line-gate cases).

• Layer 2 — the governor (optional companion plugin, v2): a free bash gate watches every
  turn-end, and exactly when a goal first fails twice — the two-strike moment — it spawns one
  read-only, fresh-context reviewer that reads the plan and code with an adversarial frame and
  names the thing Layer 1 can't see: an unverified foundation, a violated constraint from the
  plan, or a band-aid. On Claude Code the reviewer is claude -p pinned to claude-sonnet-4-6 (override via TALE_GOVERNOR_MODEL) and
  restricted to read-only tools; on Codex it's an OS-sandboxed codex exec --sandbox read-only
  (how both were verified live). It only advises — it never
  blocks; Layer 1 owns the decision. Install it if you want it:
  /plugin install tale-mode-governor@tale-mode.

  Idle cost: zero. When nothing is stuck — which is almost always — the governor is a
  few milliseconds of bash and no tokens. It spends exactly one bounded model call per stuck
  goal, drawn from your own subscription for that host. It stays a separate plugin because
  spawning headless model calls on your behalf is a capability you should opt into, not a
  default. Kill switch on both hosts: TALE_GOVERNOR=0; remove entirely with
  /plugin uninstall tale-mode-governor@tale-mode.

Can't-forget auto-arm (v2). The goal-file works, but it relies on the agent remembering to
write it. So the loop can also arm from a committed .claude/tale-mode.json — e.g.
{ "gates": ["npm test --silent", "npm run -s typecheck"] }. During a deliberate
/tale-mode:kickoff-phase phase, with uncommitted changes, the Stop hook runs those gates and
won't let the turn end until they're green — no agent memory required. Because committed gates are
arbitrary shell, they only run once you trust the file's content-hash (a one-time
echo "<hash> # tale-mode gates" >> ~/.claude/tale-mode-trust; the hook never self-trusts), and
they're AND-combined with any goal-file (the agent can add a gate, never remove a committed one).
See Security & trust.

Longer loops. Out of the box the loop stops after Claude Code's default 8 consecutive
blocked turns (a platform backstop) even if max_rounds is higher — a plugin can't change
that env var. For loops that legitimately need more, raise it once in ~/.claude/settings.json:

{ "env": { "CLAUDE_CODE_STOP_HOOK_BLOCK_CAP": "30" } }

The loop is safe without this — max_rounds + the fail-open are self-contained; the cap is
just a belt.

Optional no-progress stop. Off by default. Set TALE_NO_PROGRESS_N=3 (any positive N) and
the loop disarms cleanly after N consecutive rounds that fail with a byte-identical signature
(same command, exit code, and output tail) — an unchanged failure means the loop is anchored, and
more rounds of the same are waste. A changing failure resets the streak (that's a loop doing work).

Cross-platform (Claude Code + Codex). The skill and the autonomous loop both run on OpenAI
Codex, which loads Claude-format plugins. Two things differ there. Codex has no user slash
commands, so the phase workflows surface as the plan-phase and kickoff-phase skills instead.
And because Codex doesn't hand its hooks a trusted project root, the loop stays inert until you opt
in once with touch ~/.tale-mode-allow-cwd-root — after which it resolves the root from the
session directory. The bundled trust skill walks through this and the committed-gate trust store;
the mechanics were verified against a live Codex session, not just documented. Everything on Claude
Code is unchanged.

What the loop actually buys. Autonomy, not IQ. The block-and-retry loop, multi-round
iteration, the max_rounds give-up, the agent self-arming a goal, and the needs_user pause are
all verified live (claude -p). But capable models already self-regulate — they foundation-check
and bail correctly on their own — so the loop is mostly a safety net for the rare genuine stall,
not a daily multiplier. Think seatbelt: proven to work, worth wearing, most valuable on the bad
day. The design rationale and build log — including the bugs an adversarial pass caught in this
very hook — are in docs/autonomous-loop-design.md.

What makes it different

Beyond the general bones (stage map → delegate → verify → self-critique, domain
patterns, triggers), Tale Mode adds the three disciplines that separate "looks
right" from is right:

1. Receipts / provenance — decisions trace to a source; nothing laundered in.
2. Independent adversarial review — a separate agent that reads ground truth
   and tries to break the work, not just same-context self-critique (which can't
   see its own blind spot).
3. Verify against ground truth — re-read the actual file / run the actual
   command, not "does my output match my plan" (internal consistency ≠ correctness).

Plus a right-size throttle so it doesn't ceremony-ize trivial tasks, and
ask-on-genuine-forks instead of guessing.

Install

Two commands inside Claude Code:

/plugin marketplace add alicicek/tale-mode
/plugin install tale-mode@tale-mode               # core: skill + commands + agent + the free loop
/plugin install tale-mode-governor@tale-mode      # OPTIONAL: the stuck-loop governor (zero idle cost)

Then restart Claude Code (or run /reload-plugins). The core plugin is enabled on install
(defaultEnabled), so the skill, the /tale-mode:plan-phase + /tale-mode:kickoff-phase commands,
the plan-reviewer agent, and the free Layer-1 loop are live immediately. The governor is a
separate, optional install — it spawns one read-only model call per stuck goal, and nothing
otherwise (see Autonomous loop).
Requires Claude Code ≥ v2.1.154 (kickoff auto-arm verified on ≥ v2.1.195; older builds degrade
gracefully to agent-armed goals).

Verify it loaded: /skills lists tale-mode · /tale-mode:plan-phase appears in the
/ menu · /agents lists tale-mode:plan-reviewer.

Not on Claude Code? The discipline itself is portable — the skill at
plugins/tale-mode/skills/tale-mode/SKILL.md
works on the claude.ai app: put it in a folder named tale-mode, zip it, and upload at
claude.ai/customize/skills. The plugin machinery (commands, agent, autonomous loop) is
Claude-Code-only.

Security & trust

A plugin loads into your agent's context and, in Claude Code, runs with the same
privileges you have — so "only install plugins you trust" is the right instinct (it's
Anthropic's own advice).
The honest answer to "is this safe?" isn't trust me — it's read it, it's tiny. The whole
plugin is plain Markdown, four small shell scripts (a Stop gate, a tiny SessionStart injector, a phase marker, and a plan-mode read-only auto-approver), and small JSON manifests —
a handful of files you can skim in a few minutes.

What it does / doesn't do

• No telemetry, no analytics, no background network calls. The skill, command files,
  and the loop hook send nothing anywhere.
• Install/uninstall is Claude Code's built-in /plugin mechanism. It does not
  hand-edit your ~/.claude/settings.json hooks or permissions — it only records the plugin
  in a Claude-Code-managed enabledPlugins registry. /plugin uninstall tale-mode@tale-mode
  removes everything (skill, commands, agent, hooks) cleanly, with no settings surgery.
• The capabilities worth flagging:
  1. the bundled plan-reviewer agent is granted Bash + WebFetch so it can run your
     project's checks and verify cited sources — only when you invoke a review, under
     Claude Code's normal permission prompts.
  2. the always-on SessionStart hook prints a short, fixed reminder of the core disciplines
     into every session (it reads nothing, runs no project input, makes no network calls). This is
     the one ongoing cost: ~200 tokens of static context per session (a one-time injection, not a
     per-turn model call).
  3. the autonomous-loop Stop hook is on by default and is silent on a normal turn. It arms
     from two sources you control: an agent-written .claude/active-goal.json (runs that file's
     check), and — only during a deliberate /tale-mode:kickoff-phase phase with uncommitted
     changes — a committed .claude/tale-mode.json whose content-hash you've trusted (runs that
     config's gates). A repo's gates never run until you add their hash to
     ~/.claude/tale-mode-trust — a manual, user-only step; the hook never self-trusts (the
     bundled trust skill documents the exact commands). Read
     plugins/tale-mode/hooks/stop-goal-loop.sh
     (~420 lines) so you know exactly what runs and when.
  4. the phase-marker hook (mark-phase.sh, a UserPromptSubmit hook) writes a session-scoped
     .claude/tale-mode.phase.<id>.json when you run /tale-mode:kickoff-phase, so the Stop hook
     knows a build phase is active. It only writes that marker and always exits 0 with no output.
  5. the plan-mode read-only auto-approve hook (approve-readonly.sh, PreToolUse on Bash)
     kills the wall of permission dialogs during plan-mode investigation: only when the
     session is in plan mode, it auto-approves a shell command only when every segment is a
     whitelisted local read-only binary with no writing flags — no redirects (beyond /dev/null),
     no substitution/heredocs, no network binaries, no sensitive-looking paths (.ssh, .env,
     credential, token, …). It can only ever remove a dialog you'd have said yes to: its sole
     possible output is "allow", it never denies or blocks, and anything it can't prove safe falls
     through to the normal prompt. For a Bash command this approval is the sole gate (plan
     mode blocks the Edit/Write tools, not a shell command's own writes), so the classifier is
     default-deny and adversarial — it rejects $/backtick/backslash/substitution/heredoc, every
     non-/dev/null redirect, quote-obfuscated flags, and any un-whitelisted binary or flag; it
     was hardened against an adversarial review that broke an earlier blocklist version. Residual
     risk (a whitelisted read of a non-denylisted path, not writes) and the fail-case-heavy test
     suite are spelled out in SECURITY.md. Kill switch: TALE_PLAN_APPROVE=0.
  6. the Layer-2 governor (separate, optional plugin) is one type:"command" hook
     (governor.sh) on both hosts — a free bash gate that spawns one read-only reviewer only
     when a goal loop has failed exactly twice. On Claude Code the reviewer is claude -p with
     its tool set restricted to Read/Grep/Glob (no shell, no writes, nothing that can
     prompt); on Codex it's codex exec locked to --sandbox read-only (OS-enforced;
     probe-proven unable to write even /tmp) and additionally gated on the same cwd-root opt-in
     the loop uses. A recursion sentinel keeps the child from re-triggering the hook, and the
     finding is posted as an advisory message — never a decision. Kill switch: TALE_GOVERNOR=0.
     Read plugins/tale-mode-governor/hooks/governor.sh
     (~130 lines) before installing.
• It never asks Claude to read secrets, weaken security, or run destructive commands. The
  whole point is to make Claude more careful.

Read these before you trust it (all under plugins/tale-mode/):
skills/tale-mode/SKILL.md · skills/plan-phase/SKILL.md · skills/kickoff-phase/SKILL.md ·
skills/trust/SKILL.md · skills/seed-gates/SKILL.md · skills/end-phase/SKILL.md ·
commands/plan-phase.md · commands/kickoff-phase.md ·
agents/plan-reviewer.md · hooks/stop-goal-loop.sh · hooks/session-start.sh ·
hooks/mark-phase.sh · hooks/approve-readonly.sh · hooks/hooks.json ·
output-styles/tale-mode.md.

Found a problem? See SECURITY.md.

Tuning — effort & orchestration

• Model pairing. Run the worker on the strongest reasoning model you have — the
  method spends capability on fan-out and verification. Keep the reviewer on a
  different model than the worker (the bundled plan-reviewer pins one for exactly
  this reason): different training means different blind spots, and the deterministic
  gate — a real test's exit code — stays the final arbiter because it has none.

Two more independent dials, once it's running:

• Effort = reasoning depth. Default xhigh for planning, review, and
  execution — deep but responsive. Use max only for the single hardest
  reasoning passes (a thorny architecture call; reviewing a money/security
  change); it's slower with diminishing returns and can over-deliberate, so it's a
  poor everyday default even on an unlimited plan.
• Multi-agent orchestration (e.g. Claude Code's "ultracode"). Turn it on for
  big, multi-step, high-stakes work (migrations, audits, comprehensive plans) — it
  fans out agents and adversarially verifies. Overkill for small tasks; the
  right-size throttle keeps it from over-firing.
• On an unlimited plan: optimize for correctness + your own latency tolerance,
  not cost. Lean toward xhigh + orchestration-on-big-things — but don't
  cargo-cult max-everything.

Does it actually work?

Be skeptical of eval numbers — including any you'd see quoted for a tool like this. A skill that
asserts "the model now plans and self-critiques" will trivially pass an eval that checks for
planning and self-critique, while the un-skilled baseline "fails" assertions it was never asked to
satisfy. A 100%-vs-0% result like that is circular. The real test is output quality on hard tasks.

To judge it yourself: run the same genuinely-hard task twice (with and without the
mode), then have a fresh session adversarially review both outputs against the
source. Look for fewer stale claims, sourced decisions, and caught traps — not for
the model "sounding more thorough."

This repo was built with its own method: SKILL.md was run through the
plan-reviewer agent it ships, and the findings — plus the fixes they produced —
are in the commit history. (A receipt — the discipline the skill itself demands —
instead of a "trust me.")

What's in the box

tale-mode/                                 (repo — also the plugin marketplace)
├── .claude-plugin/
│   └── marketplace.json                   # makes the repo installable via /plugin
├── README.md · LICENSE · SECURITY.md
├── docs/                                  # rationale + notes (not shipped in the plugin)
│   ├── ARCHITECTURE.md                    #   the map: layers, loop mechanics, trust model
│   ├── autonomous-loop-design.md          #   design rationale + build log
│   ├── autonomous-loop-v2-design.md       #   v2 (committed-config auto-arm) design
│   ├── codex-governor-spike.md            #   Codex governor go/no-go research note
│   └── HOOKS.md                           #   optional deterministic typecheck/lint gates
├── tests/
│   ├── test-stop-goal-loop.sh             # tests for the Stop loop hook (164 checks / 56 cases)
│   ├── test-session-start.sh              # tests for the SessionStart hook
│   ├── test-mark-phase.sh                 # tests for the phase-marker hook
│   ├── test-skills.sh                     # structural lint for the skills + output style
│   ├── test-governor.sh                   # tests for the governor hook (both hosts, stubbed)
│   ├── test-approve-readonly.sh           # tests for the plan-mode auto-approve (118 checks, fail-case heavy)
│   └── verify-cross-platform.sh           # the one-shot deterministic gate (suites + validate + Codex shape)
└── plugins/
    ├── tale-mode/                         # CORE plugin (free)
    │   ├── .claude-plugin/plugin.json     # metadata (defaultEnabled)
    │   ├── skills/
    │   │   ├── tale-mode/SKILL.md         # the discipline (auto-activates on "tale mode")
    │   │   ├── plan-phase/ · kickoff-phase/   # the phase workflows as skills (the Codex trigger)
    │   │   └── trust/ · seed-gates/ · end-phase/  # helpers (explicit-invoke only, no code execution)
    │   ├── commands/                      # /tale-mode:plan-phase · /tale-mode:kickoff-phase
    │   ├── agents/plan-reviewer.md        # the independent adversarial reviewer
    │   ├── hooks/
    │   │   ├── hooks.json                 # wires the Stop + SessionStart + UserPromptSubmit + PreToolUse hooks
    │   │   ├── stop-goal-loop.sh          # goal loop + committed-config auto-arm (Layer 1)
    │   │   ├── session-start.sh           # always-on discipline injection (SessionStart)
    │   │   ├── mark-phase.sh              # writes the phase marker on /tale-mode:kickoff-phase
    │   │   └── approve-readonly.sh        # plan-mode-only auto-approve for provably read-only shell
    │   └── output-styles/tale-mode.md     # opt-in output style (selectable via /config)
    └── tale-mode-governor/                # OPTIONAL companion (one model call per stuck goal)
        ├── .claude-plugin/plugin.json     # metadata (depends on tale-mode)
        └── hooks/
            ├── hooks.json                 # Layer 2: one command hook, both hosts
            └── governor.sh                # bash gate -> read-only claude -p / codex exec reviewer

SKILL.md is the whole methodology and is the only file the claude.ai app needs.
Everything else adds the slash-command, sub-agent, and autonomous-loop machinery that
Claude Code uses.

Managing / removing

It's a normal Claude Code plugin — manage it with the built-in commands (or just ask
Claude, e.g. "remove tale mode", and it'll point you here):

/plugin uninstall tale-mode@tale-mode             # remove the core (skill, commands, agent, loop)
/plugin uninstall tale-mode-governor@tale-mode    # remove the governor (if you installed it)
/plugin disable   tale-mode@tale-mode             # turn it off but keep it installed
/plugin update    tale-mode@tale-mode             # pull the latest

Uninstall is clean: it removes the plugin's files and its enabledPlugins entry, and never
touches the rest of your settings.json. (A goal-file you armed in a project, e.g.
.claude/active-goal.json, is harmless once the hook is gone — delete it if you like.)

Contributing

Issues and PRs welcome. This repo is dogfooded — if you're proposing a change to
the methodology, run it through the plan-reviewer agent first and include what it
found (that's the receipts discipline applied to
the repo itself). Keep edits to SKILL.md host-agnostic; put Claude Code-specific
assets under plugins/tale-mode/.

License

MIT licensed — see LICENSE.