Search "Claude Code skills" and you get lists. The 10 I actually use. I tried 100+, these 6 are best. 345 skills, curated.
They are useful, and they all share a limit: the author installed a pile of skills, formed an impression, and wrote it up. That is a review, not a track record.
We are in a different position, so this is a different list. jurniti runs 78 project skills, committed to one repo and shared by a fleet of Claude Code and Hermes agents that work continuously on production infrastructure — shipping code, auditing our own SEO, reviewing our own pull requests. Skills here are not evaluated. They are load-bearing or they get deleted.
So: which ones changed an outcome.
The one that paid for all the others
A code-review skill, run as a hard gate before anything merges.
The honest version of why it earns its place: it catches things we were confident about. On the day this post was written, an agent audit produced a set of changes that passed every test suite in the repo — and the review pass found that one of them had silently pushed a build step past a 32 KiB execution cap. Nothing was red. The step would simply have been refused the next time anyone tried to use it, and the failure would have surfaced weeks later as "why can't we rebuild this."
That is the shape of what review skills are for. Not typos — a linter finds typos. The class of defect where the work looks finished and the guard that would have objected was never consulted.
If you install one skill, install the one that argues with you.
The category that actually compounds: skills that write skills
The highest-leverage skill we run does not do work. It documents work that is finished, into a searchable store the next session reads.
The mechanic is dull and the effect is not. Solve a problem, write down the symptom, the false starts, and the fix. Next time the symptom appears, the answer is a lookup instead of an investigation. Our store is at 400-odd documents now, and the compounding is real: a class of problem gets solved once expensively and thereafter cheaply.
The trap is writing it for yourself. A learning doc is read by an agent that was not in the room, so it needs the symptom stated the way it appears, not the way you eventually understood it. If the title is the root cause, nobody searching the symptom will find it.
Skills that hold a line, not skills that do a task
The pattern that keeps working: a skill whose entire job is to refuse.
Ours include a "do not do this" register of invariants, each tied to a real incident and a named test, and a set of pre-flight checks that must pass before a deploy. They produce no output on a good day. That is the point — they are cheap when things are fine and they are the only thing standing there when they are not.
There is a caveat worth stating plainly, because we learned it the hard way. A rule written as prose in a skill file drifts. We had a guarantee stated emphatically in bold, and it failed three times, escalating each time, until the operation moved into a script the skill calls rather than a convention the skill describes. Where a guarantee actually matters, the skill should be unable to violate it, not asked not to.
Packs: what a large library is genuinely good for
Three vendored packs run on our template boxes — separate machines, not part of the 78 above — and each is a fair example of when volume beats curation:
- 46 marketing skills (Corey Haines' set, MIT) — CRO, copy, SEO, ads, pricing, launch. You will use six. The other forty are there for the week you need pricing and have never priced anything.
- 49 motion-graphics skills — kinetic type, chart animation, GSAP, Three.js, Manim, Remotion. Same shape: a long tail you cannot predict in advance.
- 15 founder skills — the smallest pack and the one with the highest hit rate, because the domain is narrow.
The pattern across all three: a pack earns its place when you cannot predict which item you will need. For a domain you work in daily, a pack is worse than three skills you wrote yourself, because your own three know your specifics.
How to tell shelfware from a keeper, before you install 100
Four questions, in the order that saves the most time:
- Does the description match how you would ask? Skills are selected by description. One named for a framework wins only when you say that framework's name; one described by the situation gets found when you describe your situation. This single property separates used from unused more than quality does.
- Does it refuse anything? A skill that only ever says yes is a prompt you could have typed. The ones that earn permanent installation have an opinion about what not to do.
- What does it produce on a good day? If the answer is "nothing," that is often correct — a guard should be quiet. If the answer is "a summary of what I already knew," delete it.
- Would it survive being wrong once? A skill that quietly does the wrong thing is worse than no skill. Prefer ones that fail loudly, and treat any skill that makes a claim you cannot verify as unfinished.
The cost nobody mentions
Every installed skill's description is loaded so Claude can judge relevance. A hundred skills is a hundred descriptions spent before work begins, and — worse — a hundred chances to select the wrong one. Two skills with overlapping descriptions do not average out; they trade off unpredictably, and you will not notice which fired.
We run 78, and no single agent loads all 78. They are split by job: the SEO agent has its loop and its workspace skills, the review agent has its gates, the build agents have theirs. Split by agent, not by ambition. That is easier when each agent has its own machine, which is the honest reason we ended up building Claude Code hosting at all.
Where skills want to run
Most of the interesting ones are not interactive.
A skill that sweeps your search console every Monday, or watches a deploy, or audits a directory nightly, needs a machine that is awake. On a laptop those become things you remember to run. On an always-on box they become things that happen, and the skill library plus its accumulated state survives every restart.
That is the whole pitch for running Claude Code on a server: your login stays in your VM, the skills stay installed, and the work continues after you close the lid. If you want to see the shape of it, our motion-graphics and marketing skill packs are forkable as running agents rather than repos to clone.
The short version
Install the skill that argues with you. Install the one that writes down what you learned. Keep the guards that produce nothing on a good day. Take packs for domains you visit rarely and write your own three for the domain you live in.
And check the description before the content — it is the line that decides whether the skill is ever used at all.