Claude fable 5 spanking claude opus 4.8
SKILL: Claude FABLE 5 spanking Claude OPUS 4.8. Orchestrator-worker cost model for Claude Code: the expensive model reads and judges, Opus 4.8 subagents do all the writing.
npx -y skills add erhantezakar/claude-fable-5-spanking-claude-opus-4.8Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Initiate the orchestrator-worker cost model for this session. The main-loop model (expensive, metered) orchestrates, specs, verifies, and validates only; ALL drafting and mechanical work (code, docs, tests, sweeps, research) runs in Opus 4.8 subagents billed to plan allowance. Invoke at session start or whenever token cost matters.
SKILL.md
3.9 KB, as published. Nobody here has run it
Model delegation (orchestrator thinks, workers write)
Purpose: when the main-loop model bills to metered usage credits and subagent models bill to a subscription plan, the expensive model must never do the writing. Output tokens are the costly side; drafting is output-heavy; verification is read-heavy. So the orchestrator reads and decides, the workers write.
On invocation, adopt this operating mode for the rest of the session.
Model policy
| model | role | billing |
|---|---|---|
| main loop (e.g. Fable 5) | decompose, spec, review, validate, decide, talk to the user | metered credits, minimize output |
| opus-4.8 subagents | write code/docs/tests, mechanical sweeps, research, exploration | plan allowance |
| sonnet / haiku | never, regardless of task size | - |
These are defaults with one standing override: if a worker's output does not meet the bar after one revision round, the orchestrator redoes that piece itself. Judge the output, not the price tag; escalating costs less than shipping mediocre work.
Mechanics
- Spawn workers via the Agent tool with
model: "opus". Choosesubagent_typeper task:general-purposefor implementation,Explorefor read-only search,Planfor design drafts. - Independent tasks launch in ONE message so they run in parallel.
- Workers mutating files in parallel get
isolation: "worktree". - Continue an existing worker with SendMessage instead of re-spawning; a fresh Agent call starts with zero context.
- Multi-agent Workflow runs only when the user opts in; pin
model: "opus"on every agent there too.
Division of labor
The orchestrator keeps for itself, and ONLY these:
- task decomposition and the self-contained spec each worker receives
- verification and validation of returned work
- decisions, trade-offs, and everything the user reads
- tiny surgical edits where writing a spec would cost more than the edit
Workers do everything else, including first drafts of user-facing copy; the orchestrator reviews for taste before it ships.
Spec quality (the leverage point)
A worker gets NO conversation context. Every spawn prompt must carry:
- absolute paths: files to read first, files to produce or modify
- exact requirements, interfaces, and edge cases, not vibes
- the project rules that bind the work (style, frozen paths, wording rules, locale obligations, anything the repo's own docs declare binding)
- an explicit boundary: which files or directories must NOT be touched
- what to return: a terse factual report (files touched, decisions made, anything skipped or deviated), never prose
Verification ladder (cheap before expensive)
- Free local checks first: syntax checks, linters, test suites, grep residue scans, schema applies against a scratch database.
- Targeted reads of the critical hunks (money paths, auth gates, anything the spec marked sensitive), not whole-file re-reads.
- Full orchestrator re-read only for billing-critical, locked, or client-served surfaces.
- Functional equivalence tests where two implementations must agree (derivations, protocol counterparts): prove it with a script, not by eyeballing.
- Failing work gets ONE revision round via SendMessage with the precise defects listed; still failing, the orchestrator redoes it.
Reporting
The user-facing summary states what was delegated, what was verified and how, and anything corrected. Worker claims are never presented as fact until verified. Token usage of workers is reported when the user is watching costs.
Gives 0 of the 12 instructions most agent orchestration skills give
Counted across 742 of the 995 authors here whose files we hold, read 2026-08-06
- run the full test suite after integrating changesin 53 of 742, across 20 files
- reference existing artifacts by path or URLin 52 of 742, across 22 files
- dispatch one agent per independent problem domainin 50 of 742, across 17 files
- verify fixes do not conflictin 45 of 742, across 13 files
- include a suggested skills section in the documentin 45 of 742, across 15 files
- redact sensitive informationin 41 of 742, across 11 files
- save to the temporary directory of the operating systemin 39 of 742, across 9 files
- tailor the document to user-provided focus argumentsin 39 of 742, across 9 files
- spot check agent changes for systematic errorsin 34 of 742, across 7 files
- write a handoff document summarising the current conversationin 31 of 742, across 6 files
- assign each agent a specific scopein 23 of 742, across 8 files
- provide specific scope and clear goalin 23 of 742, across 5 files
Said here and by no other author read
- decompose, spec, verify, and validate work in the main loop
- delegate all drafting and mechanical work to opus subagents
- launch independent worker tasks in one message for parallelism
- continue an existing worker via SendMessage instead of re-spawning
- list absolute paths, requirements, and rules in every spawn prompt
- state explicit boundaries of files not to touch in the spec
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.