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

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

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.

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.

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

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

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.

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 sonnet (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).

Optional needs_user notifier. Off by default. When a loop pauses on needs_user, the hook fires the user's opt-in notifier — TALE_NOTIFY_CMD, or an executable ~/.claude/tale-mode-notify (user-home, so a malicious repo can't plant one) — with the ask text as $1, once per distinct ask, backgrounded and fail-open: a missing, crashing, or slow notifier never affects the pause itself. Wire it to anything that reaches you — an ntfy wrist ping, a phone-call bridge, a Slack webhook.

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.

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.

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.

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.

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

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

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.

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

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

MIT licensed — see LICENSE.