| name | library-reference-distillation |
| description | Methodology for starting a new library-reference distillation skill โ one that turns an external library (nuqs, zod, framer-motion, msw, react-hook-form, emilkowal-animations) into an idiomatic-usage rule pack โ or evolving one against a new upstream release. Distills the conventions empirically shared across shipped library-ref skills in this repo โ the source-priority ladder (docs โ blog/changelog โ issues โ types โ examples), version pinning that inverts with API velocity, the universal 4-tier category ladder (CRITICAL setup โ HIGH isolation โ MEDIUM composition โ LOW edge cases), the 4-slot When-to-Apply template, the failure-gap exemplar heuristic (privilege production lessons over API restatement), and metadata.references[] as cite-set checksum. Triggers on "I want to write a skill for library X", "refresh against new upstream", "where should I source rules from", "what categories should this skill have", and on /dev-skill:new for a library-reference distillation. |
Library-Reference Distillation โ Archetype Playbook
Methodology distillation of the conventions that hold across shipped library-reference distillations in this repo โ the archetype that turns one external library into an idiomatic-usage rule pack. Not a generator; a constraint set on the editorial decisions /dev-skill:new cannot make for you.
This is the archetype layer that sits above /dev-skill:new and /dev-skill:ingest. The generator handles the structural shell. This skill handles the four decisions you re-make for every library-ref skill: where to source from, how to pin against version drift, how to shape categories and rules, and how to keep the metadata an honest checksum.
When to Apply
Use this skill when:
- Starting a new library-ref distillation (the library has docs and a stable surface area you want to capture as idiomatic rules)
- Evolving an existing library-ref skill against a new upstream release or major version bump
- Reviewing a draft library-ref skill that "feels like the docs rewritten"
- Picking categories and a prefix scheme for a new skill and the choices feel arbitrary
- Deciding whether to pin the upstream version in
SKILL.md heading or only in metadata.json
- Refreshing a skill where you suspect rule drift from upstream (the
openai-codex-rust-patterns lesson: codex-rs drifts hard between snapshots)
This skill is not for:
- Code-atlas distillations (e.g.,
openai-codex-rust-patterns, opencode-ts, nextjs-ppr-patterns) โ sources are a real repo at a pinned HEAD, not upstream docs. Sibling archetype playbook still to be extracted.
- Methodology distillations (e.g.,
radical-simplification, deterministic-metric-design) โ sources are named humans and their canon, not a library.
- Scaffolders (e.g.,
expo-design-system-scaffolder) โ composition workflow, not a rulebook.
How to Use
The four categories are orthogonal decisions you make once per skill. Match the symptom to the move:
For category overviews and ordering rationale, see references/_sections.md.
Rule Categories
| # | Category | Prefix | Move | Rules |
|---|
| 1 | Source Selection | source | Where to mine from; what makes a rule load-bearing | 2 |
| 2 | Versioning | pin | How to pin against API velocity; how to refresh | 2 |
| 3 | Rule Shape | shape | The universal 4-tier ladder; the When-to-Apply template | 2 |
| 4 | Metadata Discipline | meta | references[] as honest cite-set checksum | 1 |
Quick Reference
1. Source Selection
source-priority-ladder โ Docs โ blog/changelog โ GitHub discussions โ types โ examples; the ladder inverts only when the library publishes an llms.txt (Effect)source-failure-gap โ Privilege rules that capture what docs omit and production exposed; if a rule just restates the API, cut it
2. Versioning
pin-by-velocity โ Stable APIs (Zod, RHF) โ version lives in metadata.json only; fast-moving APIs (nuqs v2.5โv2.8, Tailwind v4) โ explicit range in SKILL.md headingpin-refresh-vs-head โ When evolving, diff your skill against upstream HEAD; codify the drift lessons (codex-rs codex.rs โ session/ split is the canonical example)
3. Rule Shape
shape-category-ladder โ Every shipped library-ref skill ladders CRITICAL setup โ HIGH isolation/perf โ MEDIUM composition/integration โ LOW edge cases/polish; pick category names that map onto this, do not invent a new shapeshape-when-to-apply-template โ 4 slots: import-statement trigger + problem-domain language + frequency signal + explicit NOT-to-do boundary pointing to sibling skills
4. Metadata Discipline
meta-references-checksum โ metadata.references[] is the exact set of URLs cited in rules โ no superset, no subset; if it diverges, either the rules or the metadata is lying
Related Skills
radical-simplification โ The thinking layer above this skill; this playbook is itself an instance of the "reduce โ constrain โ name the invariant" moves applied to skill-authoringskill-authoring โ Cross-archetype skill-authoring conventions; this skill is the library-reference specializationdeterministic-metric-design โ Methodology-distillation sibling; demonstrates the same archetype patterns applied to a different archetype (proves the per-archetype playbook idea generalizes)
Authoring Note
These rules are load-bearing, not decorative. They were extracted by tracing where rules in 5 shipped library-ref skills cited their sources (nuqs, zod, react-hook-form, effect-ts, emilkowal-animations). Each rule names the wrong default the author makes when these conventions are absent. If a rule restates something /dev-skill:new already handles, cut it. Coverage is proven by /dev-skill:eval on real library-distillation prompts, not by rule count. When the next archetype playbook (code-atlas, methodology, scaffolder, runbook) is extracted, the patterns that re-appear here are candidates for promotion to a generic skill-authoring skill; the ones that diverge stay archetype-specific.
