현재: v6 (2026-10-10). 라이브 스킬: fable-mode (루트 SKILL.md), fable-opus, fable-sonnet, double-check, execution-guardrails. 순위: 하이쿠 → Opus → Sonnet → 사용자. fable-fable, fable-haiku 그리고 v3 agents/ 라우팅 은퇴한 사람들입니다 — SUPERSEDED.md 참조. 아래 섹션에서 이들을 설명합니다 역사로 남겨진다.

클로드가 대규모 과제에서 수행할 수 있는 실행 규율: 작성된 단계도, 런타임이 허용하는 경우 이름 있는 에이전트, 모든 단계에서 검증 검사가 가능합니다. 실제로 실패, 회의적인 자기 평가, 그리고 필수적인 콜드 재확인 무엇이든 전달됩니다.

이건 체크리스트일 뿐, 능력 이식이 아닙니다. 세 번이나 벤치마크했으니 README 무엇을 하고 무엇을 하지 않는지 말할 수 있습니다(증거 참조).

사다리

각 단계마다 한 가지 스킬, 동일한 코어 루프, 해당 티어의 알려진 실패 모드에 맞춰 조정:

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.