Fable 5: the retirement prompt that writes a skill library

The repository is one prompt, one licence and nothing else

Open the repository and you find two entries: LICENSE and README.md. The licence is MIT, the default branch is main, and the last push landed on 2026-07-02. There are no releases, no homepage, and no primary language reported at all, because a repository holding a single Markdown file has nothing for GitHub to classify. That README is not documentation of a tool. It is the tool: a prompt addressed to a model, written in the second person, opening on the fiction that the reader is a distinguished fellow on the project who is retiring. Whatever a session produces stays outside version control, which means you can compare two generated libraries but never diff one against a checked-in baseline. The repository description says the same thing, typos included: `Thsis is a prompt that will create skills by Fable 5 before it retires and your cheaper models can use those skills.` Read it as a template you paste into a session rather than a package you install. The opening paragraph sets the bar in four verbs: cheaper sessions must be able to debug, extend, validate and eventually advance the project at the standard the retiring model holds today. That last clause is the demanding one, since it asks a generated library to match a person rather than tick off a checklist.

Phase 1 forbids writing a single skill until the repository has been read

The first phase carries an explicit parenthetical: no skill authoring yet. What it wants instead is an investigation conducted with the manners of an incoming principal engineer, and the list of places to look is specific. README, manifest and contributor docs. The build system. The test suite and how it is actually run. CI config. Docs directories. Git history. Open TODO and FIXME hotspots. Issue-shaped artifacts. Generated-data and deploy conventions. Any project memory or notes available to the session. Three entries deserve a second look. How the test suite is actually run is listed separately from how it is documented, which is a bet that the two disagree. Git history is requested for what changed, what got reverted, and what stalled on dead branches, so past failures count as data instead of noise. Issue-shaped artifacts catches design notes that never reached the docs directory. Nothing is written during this phase.

Five questions maximum, and only for what the repository cannot answer

Discovery ends at one interactive gate, and the gate is capped hard: at most five questions, asked only for what the repo cannot tell you. Five candidates are offered, and they are the sort of thing no amount of code reading recovers. What is the hardest live problem right now. What unwritten discipline rules exist, glossed as things you are not allowed to do that no document states. Who the audience for this library is and what that audience does not know. What past failures cost the most time. And what beyond state of the art means for this project. Four of the five are institutional memory held by one person, which is the reason the prompt exists at all. A session that skips this phase can still produce twelve plausible skills. It cannot produce the unwritten rules, and those are the ones that stop a cheaper session from quietly undoing a settled decision. Answers are folded into everything that follows, which is why the gate sits before Phase 2 rather than beside it, and why the institutional memory ends up inside the change-control and failure-archaeology skills instead of in a separate note nobody opens.

Twelve core skills, four advanced ones, and a budget of 10 to 16

Phase 2 hands the model a taxonomy and then instructs it to adapt that taxonomy to whatever Phase 1 turned up: merge categories that are thin here, split ones that are deep, add domain categories the author never imagined. The CORE tier names twelve skills, running from `<project>-change-control` and `<project>-debugging-playbook` through `<project>-failure-archaeology`, `<project>-architecture-contract`, `<project>-config-and-flags`, `<project>-build-and-env`, `<project>-run-and-operate`, `<project>-diagnostics-and-tooling`, `<project>-validation-and-qa`, `<project>-docs-and-writing` and `<project>-external-positioning`, plus a `<domain>-reference` holding the theory a mid-level person lacks. The ADVANCED tier adds four more, numbered 13 to 16. Twelve plus four lands exactly on sixteen, the top of the stated 10 to 16 range, so that range only means anything once categories get merged or split. Every name is a placeholder, and `<project>` has to be replaced before a file is written. Phase 2 also fixes the execution shape: parallel agents, one skill per agent. The framing paragraph calls that multi-agent orchestration for authoring and review and states the trade plainly, token cost is not a constraint while correctness is.

GROUND TRUTH ONLY, because wrong runbooks are worse than none

One authoring rule is set in capitals, and its justification is the sharpest sentence in the file: wrong runbooks are worse than none. Every command, flag, path and claim gets verified against the repository before it is stated. Volatile facts are date-stamped, and every skill closes with a Provenance and maintenance section holding one-line re-verification commands for anything that may drift, which concedes up front that flags will move out from under the text. Knowledge has to be embedded in the file instead of pointing at private or user-specific paths as load-bearing sources. Overselling is banned in the same register, with unproven things staying labelled open or candidate. Two constraints bind the finished library. Nothing may contradict the project's own manifest or rules, and no skill may route around its change-control. A skill offering a faster path past the review gate is not a shortcut, it is a defect.

Write only inside .claude/skills/ and run no mutating git commands

The audience is fixed before anything else: a zero-context mid-level engineer, or a Sonnet-class model holding no memory of the project. That audience gets an imperative runbook voice, copy-pasteable commands, every jargon term defined exactly once, tables and checklists, and in each skill an explicit statement of when not to use it and which sibling to use instead. File layout is fixed at `.claude/skills/<name>/SKILL.md` with YAML frontmatter carrying a name and a trigger-rich description saying precisely when a model should load it, which turns the description into a routing table rather than a summary, since a model weighing two skills never reads past the frontmatter. The write boundary is absolute: write only inside `.claude/skills/`, treat the rest of the repository as read-only, and run no mutating git commands. Diagnostics get special handling, since that skill is told to ship working scripts inside its own `scripts/` directory wherever such scripts exist or can be written.

Three parallel reviewers run only after every skill exists

Phase 3 is ordered as strictly as the phases before it and begins after the whole set exists. Three reviewers run in parallel over the finished library, then a single fixer applies what they find. The FACTUAL reviewer re-verifies flags, paths, commands and citations against the repository and flags anything invented or stale, with severity defined by consequence: would it send an engineer down a wrong path. The DOCTRINE reviewer hunts contradictions with the project's own rules and between skills, overstated claims, and anything that changes behaviour without a gate. The USABILITY reviewer grades the trigger quality of descriptions, duplication where one fact has more than one home, self-containedness and scannability. The fixer applies blocking and important fixes and nothing else. Both boundaries are phrased as prohibitions rather than permissions, Phase 1 opening with no skill authoring yet and Phase 3 opening with after ALL skills exist, because a library reviewed while its members are still moving is a review of a different artifact each time. The closing deliverable is not the library by itself: an inventory with one-line descriptions, a note of what was verified by spot-check, and an explicit list of what remains uncertain.

The hardest-problem campaign wants expected numbers at every gate

The four advanced skills are where a junior session is meant to turn sharp. `<project>-<hardest-problem>-campaign` sets the pace: an executable, decision-gated campaign with numbered phases, exact commands, and expected observations or numbers at every gate, written as a branch rule of the form if you see X instead then go to Y. The solution menu has to be ranked with theory or derivation obligations attached to each candidate, known wrong paths get fenced off rather than merely mentioned, and promotion routes through the project's own change control. Success must be measurable and never judged by eye. `<project>-research-frontier` sets each milestone as a falsifiable sentence beginning with you have a result when. `<project>-research-methodology` fixes the evidence bar: one mechanism must explain all observations including the negative ones and survive assigned adversarial refutation, and a hypothesis predicts numbers before the run rather than after it. `<project>-proof-and-analysis-toolkit` rounds out the tier, asking for the first-principles analysis methods of the domain, each written as a recipe with a worked example taken from this repository's own history.

Editorial conclusion

Reach for this when the person who understands a repository is the person about to leave it, and the sessions that follow will run on a smaller model. It does nothing for a codebase with no history to mine, because Phase 1 asks for reverted fixes, dead branches and TODO hotspots, and an empty repository leaves the authoring agents with nothing to adapt the taxonomy to. Before spending a long agent run on it, confirm the target project already has a change-control path, since every skill is barred from routing around one and nothing in the prompt creates it for you.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tomicz/fable-5-train-opus-skills-after-it-retires on GitHub