The Claude Skills Stack — what to put in yours in 2026

A stack is not a list. Composability, install order, and scope discipline separate a working Claude skills stack from a 100-skill grab bag.

· 9 min read

A friend texted me on a Sunday afternoon: "I installed 47 skills and now nothing fires right." He'd spent a weekend cherry-picking from awesome-claude-skills, claudeskills.info, and three Reddit threads, the way people pile npm packages into a side project, on the theory that more is more. When he typed "write me an SEO blog post about X," Claude offered him eight skills with overlapping descriptions and picked the wrong one roughly half the time. The grab bag had become its own problem.

This is the failure mode that distinguishes a Claude skills stack from a Claude skills list. A list is a collection. A stack is a set of skills that compose, where each one consumes the output of the one below it, and the order you install them in actually matters. Most "best 12 skills" posts you'll find for the keyword claude skills stack are lists. The post you're reading is about the stack.

A Claude skills stack is not a list

Here's the thing: the word "stack" carries a technical meaning that the marketing posts borrowing it routinely ignore. A LAMP stack is Linux, Apache, MySQL, PHP, four layers where each layer depends on the one below. A MERN stack is Mongo, Express, React, Node, same shape. The word implies layered dependency, not breadth.

A Claude skills stack works the same way. Three properties separate it from a list.

First, composability. Each skill's output is the next skill's input. A research skill produces a brief; a writing skill consumes the brief; a humanizer skill consumes the draft; a renderer turns the draft into HTML. If your skills don't compose, what you have is a toolbox, and a toolbox is not a stack.

Second, install order. Claude reads every skill's description field at the start of every session, and decides which one applies to what you typed by scoring the description against the message; when two skills compete for the same trigger (which happens more often than people admit, especially once you've installed twenty or so skills and the descriptions start overlapping in their verb choices), the one with the more specific description wins. Install order doesn't decide that on its own; description discipline does. But install order is path-dependent on tie-breaks, and you want to know which skill the agent reaches for first when ambiguity tips either way. Boring, but it works.

Third, scope discipline. Every skill in a stack covers a layer the others don't. A list might ship three "writing" skills with overlapping triggers; a stack ships one writing skill with a description specific enough that Claude never reaches for it when you wanted research. Junior stacks have 30 skills, half of which collide. Senior stacks have 8-14 skills with non-overlapping triggers. The Medium "8 Skills Every Claude Code Setup Needs" post put it well: "Junior ones run 30 and call it a stack."

What install order actually means

The skills layer of Claude Code, per the official spec, works roughly like this:

  1. Claude reads the YAML frontmatter (name, description) of every skill in ~/.claude/skills/ at session start.
  2. For each user message, Claude scores each skill's description against the message and either invokes the highest-scoring one or asks you to disambiguate.
  3. The body of the skill, the actual SOP, only loads into context when the skill fires.

That third point is the one most posts miss. A skill's body costs you nothing until it triggers. What costs you context, every session, is the description. So when you're tempted to install a 47th skill, the question isn't "do I want this skill?" The question is "is this description specific enough that Claude won't reach for it when I meant something else?"

That is another way of saying that the description is the trigger and the body is the work. Get the descriptions wrong and the stack is a mess regardless of how good the bodies are.

Install order matters in one specific way: when two skills have descriptions that score nearly identically, Claude's tie-breaking is path-dependent on which one it saw first. The clean fix is to rewrite one of the two descriptions to be more specific. The dirty fix is to delete the loser. Either beats living with the collision.

A worked Claude skills stack, fourteen skills, four layers

Here's what a fourteen-skill stack looks like when you organize by layer rather than by topic. This is one specific shape, not the only shape; the point is that the layers compose, not that fourteen is the magic number.

Layer 1, meta. Two skills that operate on other skills.

Layer 2, research. Five skills that produce briefs the writing layer consumes.

Layer 3, writing. Three skills that consume layer-2 briefs.

Layer 4, shipping and audit. Four skills that turn copy into a live page and audit the result.

Read down the layers and the composition is visible. brand-research produces a brief; landing-page-copy reads that brief; website-designer renders the copy; seo-optimizer audits the rendered page. Four skills, one workflow, one shell command's worth of orchestration, and the wall-clock from "I want a launch page for this product" to "here's a deployed page with a payment link" runs to an afternoon rather than the better part of a week.

A previous post on what's actually inside a Claude Code skill pack frequency-ranked the same fourteen skills by how often I open them. Four daily, five weekly, five at launch-time. The frequency view and the layer view are complementary; the daily skills cluster in layers 1 and 3, because that's where the writing actually happens.

Skills worth evaluating from outside the obvious catalog

A serious stack-builder reads beyond their own bundle. Roughly four sources are worth crawling before you finalize yours.

Anthropic's bundled skills (claude.com/skills and the Introducing Agent Skills announcement). The official ones, namely /code-review, /batch, /debug, /loop, /claude-api, ship with Claude Code itself, carry first-party trigger-priority, and Anthropic keeps them current against the latest model. Treat them as a floor, not a ceiling. If you can replace one with a third-party version that does the same job better, do; otherwise the bundled version is the safe pick.

P0 is one of the most-starred open-source Claude Code skill collections, and it's the strongest available answer to the "how does code get built" question, in the sense that it ships opinionated rules on the development process, testing discipline, and review steps, none of which a content-and-research stack covers on its own. Worth installing alongside any commercial stack, because the trigger surface barely overlaps with content or research skills. The DEV community three-way comparison post walks through how Superpowers and gstack differ in design philosophy ("how" vs "what") in more depth than there's space for here.

P0 is 101 stack-agnostic skills covering brand, design, content, SEO, dev, ops, growth, and research. The breadth is the value. The catch is breadth is also the failure mode, because installing all 101 is a recipe for the trigger collisions described earlier in this post. Pick the 5-10 that fill gaps your current stack has, and read each description to confirm it doesn't shadow what you've already installed.

The community catalogs (claudeskills.info, claudemarketplaces.com, and the various GitHub awesome-lists). Treat these the way you treat npm: a real source of useful packages, but also a source of unmaintained ones, where the listing date is no guarantee the underlying repo has shipped a commit in the past quarter. The signals to check are last-commit date, presence of a versioned frontmatter (version, last_verified), and whether the SKILL.md includes a reproducible example. Skills missing all three are likely abandoned regardless of how interesting the description sounds.

Rules of thumb for adding or removing a skill

Once a stack exists, the question shifts from "what should I install?" to "should this stay?" Roughly four tests.

The slot test. If you remove this skill for two weeks, do you notice? If no, the skill is occupying a slot in Claude's description-reading budget without earning it. Drop it.

The trigger-collision test. Type the three phrases this skill is meant to handle, one at a time, into a fresh Claude Code session, and watch what Claude reaches for; if it offers you a list of four similarly-described skills rather than picking yours, either the description needs a rewrite to be more specific, or one of the colliders has to go.

The scope-creep test. Read the skill's body. Does it do one specific thing, or has it grown into a swiss-army knife? Swiss-army-knife skills accumulate triggers (which collide with everything else) and accumulate scope (which makes the body harder to maintain). Split into two skills, or drop the secondary scope.

The dependency test. Does this skill produce output another skill in your stack consumes? If yes, it's load-bearing, and removing it breaks the chain that runs downstream of it. If no, run the slot test again. Orphan skills are easier to drop than chain-anchors.

Worth doing.

A note on the path-dependent nature of all of this: the right stack for a solo operator who writes content is different from the right stack for an engineer who reviews code is different from the right stack for a researcher who reads papers. The layer model is portable. The specific skills in each layer are not.


George Bristow runs P0, a curated $29 Claude Code skill pack.

Continue reading

The full stack

Unlock all 14 skills — $99 $29

One drop-in folder of production-tested Claude skills. Lifetime access.

Get the Skills Stack