Standalone skills are fancy prompts. Working skill systems use three composition patterns — nesting, progressive disclosure, and specialisation — to scale from a handful of one-off helpers to coherent pipelines that route, layer, and load on demand.
Overview
The first wave of Skills adoption produced a familiar pattern: developers built five or ten standalone skills, used them for a few weeks, and quietly stopped. The skills worked, but they did not compound. Each one was a self-contained prompt-with-files; nothing about having more of them made the system better.
Nick Spisak names the problem directly: “individual skills are just fancy prompts.” The leverage comes from composition — the architectural patterns that connect skills into systems. Three patterns have emerged in practice as the difference between a folder of helpers and a working skill architecture: nesting, progressive disclosure, and specialisation. Each addresses a different scaling pressure.
Key Concepts
- Skills — the underlying unit
- Nested Skills — skills that route to sub-skills
- Progressive Disclosure — loading detail only when needed
- Context Window — what every skill design pattern is ultimately optimising
Nesting: routing rather than proliferation
The naive approach to a growing skill library is to add another skill every time a new task comes up. After 50 skills, the library is unmanageable: which one applies? Which combination? Brendan Falk summarises the alternative pattern that emerged from community discussion: nested skills. Instead of separate create-pdf and parse-pdf skills, build a single manage-pdf skill that routes to sub-skills based on the task at hand.
The implication is structural. A nested skill is not just a folder of related prompts — it is a router. It reads the request, decides which sub-skill applies, and delegates. The user invokes one named entry point; the routing logic lives inside.
Falk’s claim is that with good nesting, this scales to 1000+ skills/sub-skills without the lookup problem. That number is speculative, but the underlying logic is sound: the user’s mental model only needs to track top-level skills (manage PDF, manage code review, manage release), while specialisation lives one level down. See Nested Skills for the concept entry.
Progressive disclosure: lean entry, deep references
The second composition pattern, articulated by Sukh Sroay in his summary of the Claude Skills plugin, is progressive disclosure. A skill loads lean — Sroay’s example is roughly 80 lines — and surgically pulls in only the reference files the current task actually needs. Zero token bloat. Full expert depth only when required.
The architecture has two layers. The top layer is the skill itself: a short instruction file that tells Claude how to approach a class of tasks. The second layer is a library of reference files (patterns, examples, framework-specific snippets, debugging guides) that the skill points to but does not include inline. When Claude invokes the skill, the lean instructions load immediately; the references are fetched on demand based on what the actual task requires.
This is the skills-layer answer to the context window constraint. Loading a 2,000-line “everything you might need to know about Django” file into every interaction is wasteful. Loading an 80-line “here’s how to think about Django problems and where to look for specifics” file, with on-demand reference loading, gives the same effective expertise at a fraction of the token cost. See Progressive Disclosure for the concept entry.
Specialisation: many narrow experts, one entry point
The third pattern is specialisation: skills as domain experts that are activated only when their domain is in play. The Claude Skills plugin Sroay describes covers 54 specialisations across 25+ frameworks and 13 languages — React, Next.js, Django, FastAPI, NestJS, Kubernetes, Terraform, and more — each one packaged as a distinct skill. The system detects the framework from context and activates the relevant expert.
Louis Gleeson describes the same pattern at the research-domain layer: claude-scientific-skills packages 140 skills across drug discovery, single-cell RNA sequencing, clinical variant annotation, molecular docking, bioinformatics, cheminformatics, proteomics, quantum computing, and laboratory automation. From a single prompt, Claude can run a full drug-discovery pipeline that cites real bioactive-compound databases, dock against AlphaFold structures, match patients to live ClinicalTrials.gov data, and produce a publication-ready clinical report.
The user does not have to know which skill applies. The activation logic lives in the skill system itself. What the user sees is one Claude Code instance that suddenly behaves like a domain specialist whenever a domain question arises.
Skills as workflow shapes
The composition patterns above describe how skills relate to each other. A separate set of examples demonstrates the kinds of work skills can encode — and these stretch the definition of “skill” beyond the original idea of “reusable instruction set.”
Kyle Mathews describes a skill that leads Claude through a structured Hegelian-dialectic deep-investigation process: thesis, antithesis, synthesis, applied iteratively to a research question. He reports forty hours of use over ten days and compares the experience to the original Deep Research feature. The skill is not a domain expert — it is a thinking shape, a procedural template that imposes a method on Claude’s reasoning.
Matt Pocock describes the same idea at a smaller scale: a /grill-me skill that interrogates the user before allowing them to commit to a PRD. It asked him 24 consecutive questions over an hour. The skill is not generating output — it is structuring a conversation that the user might not have the discipline to run alone.
These two examples reframe what skills are for. They are not just reusable prompts for tasks Claude does. They are reusable protocols for joint user-and-Claude work. The composition patterns (nesting, progressive disclosure, specialisation) apply equally to procedural skills as to domain skills — a “research” entry point can route to “Hegelian dialectic,” “literature review,” “experimental design,” each of which loads lean and pulls deeper references on demand.
Practical applications
For legal and academic work, the skill-composition patterns suggest concrete starting points:
- One nested skill per major workflow. “Manage case notes” routes to
summarise,extract-citations,compare-against-precedent,flag-procedural-issues. The user invokes one name; the routing handles the rest. - Progressive disclosure for jurisdiction-specific knowledge. A lean
legal-writingskill points to reference files for English law, Northern Ireland law, EU law. Only the relevant jurisdiction loads when invoked. - Procedural skills for academic discipline. Skills like
/grill-me(for refining research questions) and Mathews’s Hegelian-dialectic skill (for structured deep dives) have direct analogues in legal research and PhD supervision. - Specialisation libraries become institutional knowledge. A department’s accumulated skill library — encoding house style, citation conventions, ethics-review checklists, peer-review rubrics — is a transferable asset. New researchers inherit the institution’s working practices rather than re-learning them.
Limitations and open questions
- Discovery is unsolved. Even with nesting, users need a way to know what skills exist. Claude Code’s introspection helps, but at 100+ skills the discovery problem becomes a UX problem.
- Skill versioning is informal. A skill that worked under Claude 4.6 may not behave identically under 4.7. There is no standard versioning scheme; teams pin skills the same way they pin dependencies, which is to say, by hand.
- Composition can be over-engineered. A nested, progressively-disclosed, specialist-routed skill system is overkill for a folder of three personal helpers. The patterns matter once a library passes roughly 20–30 skills; below that, they add complexity without payoff.
- Procedural skills are evaluation-resistant. It is hard to measure whether
/grill-meproduced a better PRD than no skill at all. Domain skills can be benchmarked; thinking-shape skills depend on user judgement, which is harder to systematise.
Sources
- @BrendanFalk — Nested skills as the scaling pattern (1000+ skills via routing)
- @sukh_saroy — Claude Skills plugin, 54 specialisations, progressive disclosure pattern
- @kylemathews — Hegelian-dialectic deep-investigation skill as procedural template
- @mattpocockuk —
/grill-meskill, 24-question PRD interrogation - @aigleeson —
claude-scientific-skills, 140 domain-specialised skills - @NickSpisak_ — Skill architecture as systems, not standalone prompts