There are tens of thousands of Claude Code skills you can install, and the correct number to run is somewhere between eight and fifteen. I hold that opinion from an unusual seat: I maintain a marketplace of 53 skills I built for real workflows, and my own ~/.claude/skills directory — after two years of adding and ruthlessly deleting — has stabilized around thirty, of which maybe a dozen fire in a normal week. The scarce resource is not skills. It is trigger-space: the agent's ability to notice, mid-task, that a skill applies.
So this is not a tour of the ecosystem. It is a filter, and the shortlist that survives it.
The four-question filter
Every skill in my setup passed all four. Most candidates fail at least one.
1. Does it fire on its own? A skill the agent never triggers is documentation you paid context for. The single biggest quality difference between skills is whether the description is written as trigger conditions ("use when the user reports a bug, a failing test, or unexpected behavior") or as a capability summary ("helps with debugging"). I learned this maintaining my marketplace: the skills users report as "not working" are nearly always skills that work fine and trigger never.
2. Does it encode judgment, not information? Claude already knows what TDD is. A skill earns its place by encoding decisions — the order of operations, the stop conditions, the taste. Information ages and is retrievable; judgment is what you would otherwise repeat in every prompt.
3. Would I notice its absence within a week? Not "is it clever." Absence-blindness is the test. When I audit my directory, anything I cannot connect to a concrete recent moment gets deleted, however good it looked on install day.
4. Do I know what it does before it does it? A skill is instructions your agent will follow with your permissions. I read every SKILL.md before installing — full stop — and anything that fetches remote content at runtime or wants credentials gets extra scrutiny or a pass. The skills ecosystem has the same supply-chain shape as npm, with less tooling around it so far. Treat installs like dependencies, because that is what they are.
The skills that survive in my daily setup
Superpowers (the workflow family). Brainstorming before creative work, test-driven development, systematic debugging, verification before completion. These are process-enforcement skills, and their compounding effect is that sessions start gating themselves — the agent asks the scoping questions and runs the verification commands without being told. If you install one thing from this post, install this family and live with it for two weeks.
skill-creator and write-a-skill. Meta, but decisive. The skills that fit your work best are the ones you write, and a skill that scaffolds skill-writing collapses the activation energy. Every custom skill mentioned below started here. My longer writeup on what building my own skills taught me covers the failure modes — this is the tool that makes attempting them cheap.
tdd. My pinned version of test-first discipline for PHPUnit-based Laravel work, tuned to this codebase's conventions (factories, form requests, no Pest). A generic TDD skill is good; one that knows your test stack is better, and the delta is exactly criterion two above.
handoff. Packages the state of a long session — decisions made, files touched, open threads — so the next session starts warm instead of cold. Multi-session continuity is the quiet productivity killer in agent work; this is the cheapest fix I know. Full notes in my handoff skill review.
caveman. Compresses verbose agent output patterns to cut token burn on long sessions. Sounds like a gimmick, measures like a utility bill. I tested it properly in my caveman skill token-savings writeup before it earned the permanent slot.
grill-me. Interrogates you about a topic until your tacit knowledge is on paper. I use it to turn client-call context and my own undocumented decisions into briefs an agent can act on. Extraction, not generation — an underserved category. Details in the grill-me knowledge extraction review.
graphify. Builds a knowledge-graph view of a codebase so structural questions ("what depends on this service?") get structural answers. Most useful on codebases I did not write, which is most client work.
impeccable and frontend-design. The design-judgment pair: one for auditing and polishing interfaces, one for keeping generated UI from converging on the same generic Tailwind look. On a site whose theme is token-driven, these keep agent-produced components inside the system instead of adjacent to it.
The SEO family. Thirteen related skills in my directory — technical audits, schema, hreflang, sitemaps, programmatic pages, content briefs. I am not going to pretend these are for everyone; they exist because content operations are half my workload. But they are the strongest example I own of the real endgame here: a family of narrow skills sharing conventions beats one mega-skill, because narrow descriptions trigger reliably and mega-skills trigger vaguely. The blog remediation project this very article came out of ran on them.
What I deliberately do not install
Equal honesty about the reject pile, because the filter matters more than the list:
- Skills that duplicate the model. "Write clean code" skills, generic best-practice collections. They consume trigger-space and add nothing the model lacks.
- Skills that should be commands. If a thing is deterministic — format this, convert that — it wants to be a script the agent calls, not prose the agent interprets. Skills are for judgment; scripts are for mechanics.
- Overlapping skills. Two research skills with adjacent descriptions means the agent picks unpredictably between them. One slot per job.
- Anything I cannot audit. See question four. No exceptions has cost me nothing so far.
Installing is the easy 10%
The behavior change that actually made skills compound for me was maintenance. Once a month I open the directory and ask question three of every entry. Skills rot in two ways: the ecosystem ships something better, or my workflow drifts and the skill points at a problem I no longer have. Deleting them is not housekeeping — it is what keeps the trigger-space clean so the survivors keep firing.
And once your list stabilizes, the advanced layer opens up: forked contexts so heavyweight skills stop polluting your main session, dynamic context injection, background execution. That is its own discipline, and I wrote the advanced agent skills playbook for exactly the moment the basics stop being the bottleneck.
Sixty thousand skills exist. You need about a dozen, chosen against your actual week, audited before install, and deleted without sentiment. That filter — not any specific list, including mine — is the durable advice.
Fifty-three of mine are browsable on my agent skills marketplace, each carrying field notes from real use. Read them as reference implementations of the four questions above rather than as a shopping list; the descriptions are the part worth studying before you write your own.
