現在:v6(2026年10月10日)。 ライブスキル:fable-mode(ルートSKILL.md), fable-opus、fable-sonnet、double-check、execution-guardrails。ラダー:俳句→ Sonnet → Opus → ユーザー。[fable-fable、fable-haikuおよびv3 agents/のルーティング は退職しています — 詳細は SUPERSEDED.md を参照してください。以下のセクションで彼らについて説明します は歴史として記録されています。

クロードの大規模タスクにおける実行規律:書面によるステージマップ、 ランタイムが許す場合には名前付きエージェント、各段階での検証チェック、 実際に失敗、懐疑的な自己レビュー、そして必須のコールドダブルチェック 何でも配達されます。

これは能力の移植ではなくチェックリストです。READMEは3回ベンチマークされています 何をし、何をしないかを判断できます(証拠を参照)。

はしご

各段につき1つのスキル、同じコアループ、そのティアの既知の失敗モードに合わせて調整:

fable-mode

Current: v6.1 (2026-10-24) — adds an error-first judgment check and a dissent check to step 3 for prose with no answer key (see bench/judgment/). Live skills: fable-mode (root SKILL.md), fable-opus, fable-sonnet, double-check, execution-guardrails. Ladder: Haiku → Sonnet → Opus → the user. fable-fable, fable-haiku and the v3 agents/ routing are retired — see SUPERSEDED.md. Sections below that describe them are kept as history.

Execution discipline for Claude on large tasks: a written stage map, delegation to named agents where the runtime allows, a verification check at every stage that can actually fail, a skeptical self-review, and a mandatory cold double-check before anything is delivered.

It is a checklist, not a capability transplant. Benchmarked three times so the README can say what it does and does not do (see Evidence).

The ladder

Haiku  →  Sonnet  →  Opus  →  Fable 5.1  →  the user

One skill per rung, same core loop, tuned to that tier’s known failure mode:

Two always-on companions:

• execution-guardrails — verify-before-flag, warning batching, word-boundary find-and-replace. Every model, every task, whether or not the loop runs.
• double-check — the delivery gate. A panel of fresh checker agents (Haiku for mechanical checks, Sonnet for requirements, Opus to adjudicate) attacks the finished artifact. Every fable runner calls it before handing anything over.

Core loop

1. Stage map first. Numbered stages, expected output each, one verifiable artifact per stage. Living document; at most two full replans per run — a third means the requirements are ambiguous, go back to the user.
2. Delegate by name. Reasoning stages to a Sonnet worker, mechanical stages to a Haiku worker, cold checks to a read-only verifier. Workers don’t spawn workers.
3. Verify with a check that can fail. A test that runs, a file in the expected shape, a source actually fetched, an output diffed against spec. “I reviewed it and it looks right” is not a check. Name the exact command or mark the stage unverified.