{"slug": "fable-departure-skill-creation", "title": "Fable departure skill creation", "summary": "A developer retiring from a project built a complete skill library under `.claude/skills/` to enable junior and mid-level engineers, as well as smaller AI models, to debug, extend, validate, and advance the project without the original developer. The library was authored using multi-agent orchestration and includes categories such as change control, debugging, failure archaeology, architecture, domain reference, configuration, build, operations, diagnostics, validation, documentation, and external positioning.", "body_md": "| You are a distinguished fellow on this project who is retiring. Your final task: build a | |\n| complete skill library under `.claude/skills/` so that junior/mid-level engineers and | |\n| smaller AI models (Sonnet-class) can carry this project forward without you — cheaper | |\n| sessions must be able to debug, extend, validate, and eventually advance this project at | |\n| the standard I hold today. Use multi-agent orchestration (workflows) for authoring and | |\n| review; token cost is not a constraint, correctness is. | |\n| ## Phase 1 — Discover before you write (no skill authoring yet) | |\n| Investigate the repo like an incoming principal engineer: README/manifest/contributor | |\n| docs, the build system, the test suite and how it's actually run, CI config, docs | |\n| directories, git history (what changed, what got reverted, what stalled on dead | |\n| branches), open TODO/FIXME hotspots, issue-shaped artifacts, generated-data or deploy | |\n| conventions, and any project memory/notes available to you. Then ask me AT MOST five | |\n| questions, only for what the repo cannot tell you — likely: (1) what is the hardest | |\n| live problem right now, (2) what unwritten discipline rules exist (things you're not | |\n| allowed to do that no doc states), (3) who is the audience for this library and what do | |\n| they NOT know, (4) what past failures cost the most time, (5) what does \"beyond state | |\n| of the art\" mean for this project. Fold my answers into everything below. | |\n| ## Phase 2 — Author the library (parallel agents, one skill per agent) | |\n| Instantiate this taxonomy, ADAPTED to what Phase 1 found — merge categories that are | |\n| thin here, split ones that are deep, add domain categories I haven't imagined. Aim for | |\n| 10–16 skills: | |\n| CORE (every project has these): | |\n| 1. <project>-change-control — how changes are classified, gated, reviewed here; the | |\n| project's non-negotiables with the *rationale* and the historical incident behind each. | |\n| 2. <project>-debugging-playbook — symptom→triage table for this project's failure modes; | |\n| the traps that cost real time (each with its story); discriminating experiments. | |\n| 3. <project>-failure-archaeology — the chronicle: every major investigation, dead end, | |\n| rejected fix, and revert, as symptom → root cause → evidence → status, so no one | |\n| re-fights a settled battle. Mine git history and docs hard for this. | |\n| 4. <project>-architecture-contract — the system's load-bearing design decisions and WHY; | |\n| the invariants that must hold; the open known-weak points, stated plainly. | |\n| 5. <domain>-reference — the domain-theory knowledge pack a mid-level person lacks | |\n| (the field's math/protocols/standards as they apply HERE, not a textbook). | |\n| 6. <project>-config-and-flags — catalog of every configuration axis: options, defaults, | |\n| which are production vs experimental, guards; how to add one (checklist); with | |\n| re-verification commands since flags drift. | |\n| 7. <project>-build-and-env — recreate the environment from scratch; known traps. | |\n| 8. <project>-run-and-operate — running/deploying the thing: command anatomy, data or | |\n| artifact conventions, what output lands where. | |\n| 9. <project>-diagnostics-and-tooling — how to MEASURE instead of eyeball: the project's | |\n| diagnostic tools with interpretation guides; ship actual scripts inside the skill's | |\n| scripts/ dir where they exist or where you can write them. | |\n| 10. <project>-validation-and-qa — what counts as evidence here; acceptance-threshold | |\n| discipline; the certified/golden inventory; how to add tests. | |\n| 11. <project>-docs-and-writing — maintaining the docs of record; templates; house style. | |\n| 12. <project>-external-positioning — papers/releases/ecosystem: what's novel vs known, | |\n| what must be proven before claiming, reproducibility standards. | |\n| ADVANCED (the layer that makes juniors dangerous, in the good way): | |\n| 13. <project>-<hardest-problem>-campaign — an EXECUTABLE, decision-gated campaign for | |\n| the hardest live problem from Phase 1: numbered phases, exact commands, EXPECTED | |\n| observations/numbers at every gate (\"if you see X instead → branch to Y\"), the | |\n| solution menu ranked with theory/derivation obligations for each, known wrong paths | |\n| explicitly fenced off, and a validation-and-promotion protocol that routes through | |\n| the project's change control — success must be measurable, never judged by eye. | |\n| 14. <project>-proof-and-analysis-toolkit — the first-principles analysis methods of this | |\n| domain (whatever \"prove it, don't just install it\" means here), each as a recipe | |\n| with a worked example from this repo's history. | |\n| 15. <project>-research-frontier — open problems where this project could advance the | |\n| state of the art: for each, why current SOTA fails, this project's specific asset, | |\n| the first three concrete steps IN THIS REPO, and a falsifiable \"you have a result | |\n| when…\" milestone. | |\n| 16. <project>-research-methodology — the discipline that turns a hunch into an | |\n| accepted result here: the evidence bar (one mechanism must explain ALL observations | |\n| including negatives, and survive assigned adversarial refutation), hypothesis- | |\n| predicts-numbers-before-running, the idea lifecycle from experiment flag to adopted | |\n| change or documented retirement, and where good ideas historically came from. | |\n| AUTHORING RULES (bake into every agent's prompt): | |\n| - Audience: zero-context mid-level engineer or Sonnet-class model. Imperative runbook | |\n| voice; copy-pasteable commands; every jargon term defined once; tables and checklists; | |\n| each skill says when NOT to use it and which sibling to use instead. | |\n| - Format: `.claude/skills/<name>/SKILL.md`, YAML frontmatter with `name` and a | |\n| trigger-rich `description` (exactly when a model should load it). | |\n| - GROUND TRUTH ONLY: verify every command, flag, path, and claim against the repo | |\n| before stating it. Wrong runbooks are worse than none. | |\n| - Embed knowledge; don't reference private/user-specific paths as load-bearing sources. | |\n| - Date-stamp volatile facts; end each skill with a \"Provenance and maintenance\" section | |\n| containing one-line re-verification commands for anything that may drift. | |\n| - No oversell: unproven things stay labeled open/candidate. Nothing may contradict the | |\n| project's own manifest/rules, and no skill may route around its change-control. | |\n| - Write ONLY inside `.claude/skills/`; the rest of the repo is read-only; no mutating | |\n| git commands. | |\n| ## Phase 3 — Review and fix (after ALL skills exist) | |\n| Three parallel reviewers over the complete set, then one fixer: | |\n| - FACTUAL: re-verify flags/paths/commands/citations against the repo; flag anything | |\n| invented or stale (severity: would it send an engineer down a wrong path?). | |\n| - DOCTRINE: contradictions with the project's rules or between skills; overstated | |\n| claims; missing gating on anything that changes behavior. | |\n| - USABILITY: trigger quality of descriptions, duplication (one home per fact, | |\n| cross-references elsewhere), self-containedness, scannability. | |\n| Fixer applies blocking+important fixes. Then give me: the skill inventory with one-line | |\n| descriptions, what you verified by spot-check, and what remains uncertain. |", "url": "https://wpnews.pro/news/fable-departure-skill-creation", "canonical_source": "https://gist.github.com/Oclay56/85224bb167b703aed74a38ba52f3fb52", "published_at": "2026-07-04 02:13:12+00:00", "updated_at": "2026-07-04 02:18:21.312707+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "machine-learning", "ai-agents", "mlops"], "entities": ["Claude", "Sonnet"], "alternates": {"html": "https://wpnews.pro/news/fable-departure-skill-creation", "markdown": "https://wpnews.pro/news/fable-departure-skill-creation.md", "text": "https://wpnews.pro/news/fable-departure-skill-creation.txt", "jsonld": "https://wpnews.pro/news/fable-departure-skill-creation.jsonld"}}