Fable 5 Train Opus Skills After It Retires: A Prompt That Writes a Skill Library

A prompt, not a program: what the repository actually contains

The top-level entries are LICENSE and README.md. There is no package manifest, no source directory, no CI configuration, no release. The README is the deliverable, and its description states the intent plainly: a prompt that will create skills by Fable 5 before it retires, so cheaper models can use those skills. The licence is MIT. The last push was on 2026-07-02, and the repository is not archived.

That shapes everything else. You do not install this. You paste it into a Claude session that has access to the repository you care about, and the model does the work. The README is written in the second person, addressing the model directly: "You are a distinguished fellow on this project who is retiring." If you are looking for a CLI, a library, or a hosted service, this is the wrong repository and no amount of reading will change that.

The interesting part is the framing. The prompt does not ask for documentation. It asks for a skill library whose audience is "zero-context mid-level engineer or Sonnet-class model", and it explicitly says token cost is not a constraint while correctness is. That is a deliberate trade: expensive authoring sessions now, cheaper sessions later.

Who this is for, and the problem it names

The problem is stated in the opening paragraph: cheaper sessions must be able to debug, extend, validate, and eventually advance the project at the standard the retiring expert holds. The named audience is junior and mid-level engineers plus smaller AI models, described as Sonnet-class.

This is a knowledge-transfer problem, not a tooling problem. Most repositories already have a README, a contributing guide and a test suite. What they lack is the unwritten discipline: which changes are gated and why, which failure modes have already been investigated and rejected, which flags are experimental. The prompt's taxonomy is built around exactly those gaps. The change-control skill is supposed to carry "the project's non-negotiables with the rationale and the historical incident behind each". The failure-archaeology skill is described as a chronicle of "every major investigation, dead end, rejected fix, and revert", so that no one re-fights a settled battle.

That is the sharpest idea in the README. A skill library that records dead ends is more valuable than one that records only the current architecture, because the dead ends are what a new contributor cannot reconstruct from the code.

How the prompt works: three phases and a fixed taxonomy

The prompt runs in three phases.

Phase 1 is discovery, and it forbids authoring anything yet. The model is told to investigate the repository like an incoming principal engineer: README and manifest and contributor docs, the build system, the test suite and how it is actually run, CI config, docs directories, git history (what changed, what got reverted, what stalled on dead branches), open TODO and FIXME hotspots, and any project memory available. It then asks at most five questions, only for what the repository cannot answer. The README suggests what those will likely be: the hardest live problem, unwritten discipline rules, the audience and what they do not know, the past failures that cost the most time, and what "beyond state of the art" means here.

Phase 2 authors the library. The README specifies parallel agents, one skill per agent, against a taxonomy of roughly sixteen candidate skills, with instructions to merge thin categories, split deep ones, and add domain categories the prompt did not imagine. The target is ten to sixteen skills. Twelve are labelled CORE and four ADVANCED, including an executable campaign for the hardest live problem and a research-frontier skill.

Phase 3 reviews. Three parallel reviewers (factual, doctrine, usability) run over the complete set, then a single fixer applies blocking and important fixes, and the model reports the skill inventory, what it spot-checked, and what remains uncertain.

The output format is fixed: .claude/skills/<name>/SKILL.md with YAML frontmatter containing name and a trigger-rich description. The authoring rules also require a "Provenance and maintenance" section at the end of each skill, with one-line re-verification commands for anything that may drift, and date-stamping of volatile facts.

Running it: paste the prompt, answer five questions, inspect the output

There is no install step in the README, so there is no package to add. You need a Claude session with read access to the target repository and write access limited to .claude/skills/. The README's authoring rules state the constraint directly: "Write ONLY inside .claude/skills/; the rest of the repo is read-only; no mutating git commands."

The prompt itself gives the model a single instruction block, and the README is that block. There is no launcher script, so the first step is to read it in full before pasting it into a session. The opening line matters, because the whole run is framed as a role assignment: the model is told it is a distinguished fellow who is retiring, and its final task is to build the library.

After the run, verify the shape of the result against the format the prompt demands. The README states the output path as .claude/skills/<name>/SKILL.md, with YAML frontmatter carrying name and a trigger-rich description. That is the check to perform: one file per skill, frontmatter present, description written as a trigger rather than a summary. If the frontmatter is missing, the library will not load as skills regardless of how good the prose is.

The prompt also requires each skill to end with a "Provenance and maintenance" section containing one-line re-verification commands. Read those lines first when you inherit a generated library, because they are the only part that tells you which facts were expected to drift.

The Phase 1 bottleneck: five questions stand between you and a useful library

The prompt's own design admits its central weakness. Phase 1 tells the model to ask at most five questions "only for what the repo cannot tell you", and the README lists the likely ones. Those five answers are where the unwritten knowledge enters the system. The repository cannot tell the model what the hardest live problem is, or what discipline rules exist that no document states.

If you paste this prompt and walk away, the model will fill those gaps with plausible inference from the code. You will get a well-organised library that describes what the repository already says, wrapped in runbook voice. The failure-archaeology skill will be thin because git history alone rarely records why a fix was rejected. The change-control skill will list gates it observed in CI, not the non-negotiables that live in people's heads.

So the honest description of this repository is that it is a scaffold for an interview. The prompt is the structure; you are the content. Budget the time for the five answers, and treat them as the real input. The model's answers to "what past failures cost the most time" are the sentences most likely to save a future engineer a week.

A second constraint: the prompt says to verify every command, flag, path and claim against the repository before stating it, and that "wrong runbooks are worse than none". That is an instruction to the model, not a guarantee. Phase 3's factual reviewer exists to catch inventions, and its severity question is whether the error would send an engineer down a wrong path. Treat the review phase as load-bearing, not ceremonial.

Limits, failure modes, and when not to use this

The repository has no releases and no code, so there is nothing to pin, version or roll back. If a run produces a bad library, your recovery is whatever your own version control gives you. The README does not document rollback, and the prompt forbids mutating git commands, which means the model will not commit or revert for you.

Scale is another boundary. The taxonomy targets ten to sixteen skills, authored by parallel agents, with a three-reviewer pass. That is a large amount of generated text over a repository the model has just read. The prompt compensates by insisting on grounding, but grounding degrades as the surface area grows. A small repository with four real subsystems will produce a library with a lot of cross-references and not much domain depth.

The prompt also assumes the target project has the raw material: a build system, a test suite, CI config, docs directories, git history worth mining. A greenfield repository has none of that, and Phase 1 will come back empty. In that case the library will be generic, and a generic skill library is worse than no library because it looks authoritative.

Finally, the prompt is written for one specific skill format and one specific client. Nothing in the README suggests the output works with any other agent framework. If your team does not use .claude/skills/, the artefacts are prose documents, not loadable skills.

Alternatives: writing the runbooks yourself, or using an agent framework

The obvious alternative is to skip the prompt and have the retiring engineer write the runbooks directly. The difference is in who holds the pen. A human expert writing docs tends to document the system as it should be, because that is what they are proud of. This prompt forces a different sequence: mine the repository first, then answer five questions about what the repository cannot say, then author. The archaeology and dead-end sections have no natural home in a hand-written doc set, which is precisely the gap the prompt targets.

A second alternative is a general-purpose agent framework that indexes a codebase and answers questions about it on demand. Those systems retrieve; this prompt produces. Retrieval gives a cheaper model the ability to look things up, but it does not pre-commit the unwritten rules to a file, and it does not force a review pass that flags contradictions between documents. The trade is storage and review time against query-time flexibility.

A third option is to do nothing and rely on the code being readable. That works only if the repository's hardest knowledge is already in the code, which the prompt's existence implicitly denies.

Licence, maintenance and what the last push date tells you

The licence is MIT, which permits reuse and modification with the usual attribution and warranty disclaimer. The prompt text itself is the thing being licensed, so if you adapt the taxonomy for your own project, the MIT terms travel with the parts you copied. This is not legal advice; read the LICENSE file for the operative terms.

The last push was on 2026-07-02. The repository is not archived. There are no releases, so there is no version history to consult and no changelog to read before adopting. If the prompt changes, you will see it as a commit on main, not as a tagged release.

The upgrade cost is therefore low in the mechanical sense and high in the practical one. There is nothing to upgrade. Your cost is re-running the prompt against a repository that has moved on since the last run, then reconciling the new library with the old one. The prompt's own answer to drift is the per-skill "Provenance and maintenance" section with re-verification commands, which is the part to check first when you inherit someone else's generated library.

Editorial conclusion

Adopt it if you have a real repository, a real retiring expert, and the appetite to answer five questions in Phase 1: that is where the value is created, and skipping it produces a generic skill set. Do not adopt it if you expect a runnable tool, a package, or a drop-in replacement for Fable 5 sessions, because the repository ships a README and a licence and nothing else. Before running it, confirm your Claude client actually loads .claude/skills/<name>/SKILL.md with YAML frontmatter containing name and description, and read the "Write ONLY inside .claude/skills/" constraint aloud to whoever will run it, since the prompt's only guard against a wrecked working tree is that sentence.

Frequently asked questions

Official sources

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