I have an unusual reason to review skills.sh: I run a competing distribution surface. My own agent skills marketplace lists 53 curated Claude Code skills across 20 categories, and I maintain every listing by hand. So when Vercel shipped an open registry with a CLI installer and a leaderboard, I didn't evaluate it as a user looking for a productivity bump. I evaluated it as someone who has already made most of the mistakes a skills directory can make. My verdict: skills.sh gets distribution right and leaves curation as an open problem, and you should use it with that split in mind.
What skills.sh actually is
Skills.sh is Vercel's open ecosystem for agent skills, backed by the vercel-labs/skills CLI. The pitch is npm for agent knowledge: you run npx skills add <owner>/<repo> from your project root, the skill's SKILL.md files land in your repository, and Claude Code picks them up on the next session. There's a npx skills find command for discovery, and skills.sh itself works as a directory and leaderboard, ranking skills by installs.
Two design decisions matter more than the rest.
First, installation is project-scoped. Skills live in your repo, not in a global config, so a Laravel client project and a Next.js side project can carry completely different skill sets without interfering. That is the correct default. Global skills are how you end up with a React convention leaking into a Blade template.
Second, the registry is agent-agnostic. The same install flow targets Claude Code, Codex, Cursor, Copilot, and others. Since skills are markdown instructions rather than executable packages, portability is nearly free, and Vercel leaned into it.
The npm comparison is wrong in one important way
Everyone, including Vercel, reaches for the npm analogy. It's useful for explaining the install flow and misleading for everything else.
An npm package is code. It has a version, a lockfile entry, a dependency tree, and semantics that break loudly when they're violated. A skill is prose. It has no runtime, no tests that fail when the instructions rot, and no dependency resolution. If skill A assumes conventions that skill B contradicts, nothing errors. Your agent just quietly gets worse, and you spend an afternoon figuring out which markdown file poisoned the context.
This is the thing I learned operating my own marketplace that I never see in skills.sh coverage: the scarce resource in skill distribution is not hosting, it's trust metadata. On my marketplace, every skill row carries an author, a source repository, a version, and star and fork counts, because those are the only signals a visitor has before pasting someone else's instructions into their agent. Skills.sh understands this too. Registry submissions are reviewed for accuracy, structure, scope, and safety, with hard rules like no credentials in skill files and no destructive operations without explicit confirmation. That review gate is the most underrated feature of the whole project. An unreviewed skill registry would be a prompt-injection delivery network with a leaderboard.
What running a marketplace taught me about what breaks
When I built and later audited my own 53-skill catalog, the failure modes were never technical. They were editorial:
- Cannibalizing listings. I found four pairs of skills whose titles were close enough that they competed with each other in search and confused visitors about which to install. Registries at skills.sh scale will hit this constantly. Fifty community skills named some variation of "React best practices" help nobody.
- Thin descriptions. A skill listing that just restates its name gives you no way to predict what it will do to your agent's behavior. Every listing I keep now says what the skill changes, when it triggers, and what it assumes about your stack.
- Version drift. A skill written against last year's model behavior often encodes workarounds the model no longer needs. Dead instructions aren't neutral; they burn context tokens and occasionally steer the agent into outdated patterns. Somebody has to prune, and on an open registry, "somebody" is usually nobody.
Skills.sh's leaderboard partially solves discovery, but install counts measure popularity, not maintenance. The skill with 10,000 installs and no updates in eight months can be worse than the fresh one with 40 installs. When I evaluate a skill from any registry, mine included, I read the actual markdown before installing. It takes three minutes and it's the only reliable quality check that exists right now, a point I made at length in what I learned building my own Claude Code skills.
Where skills.sh genuinely wins
Credit where it's due. There are three things skills.sh does better than any curated directory, including mine:
Zero-friction install. npx skills add is a single command with no account, no configuration, and no copy-paste. Every step you remove from installation multiplies actual usage. My marketplace makes you read; skills.sh makes you run. Different jobs, but for a developer who already knows what they want, the CLI wins.
Transparency by default. The skill is markdown sitting in your repo. You can read it, diff it, edit it, and commit it. Nothing about your agent's behavior is hidden behind an API. This matters more as teams start treating skills as shared infrastructure, the way I described in my decoded guide to Claude skills.
Cross-agent reach. I built my marketplace for the Claude ecosystem. Skills.sh bet on the open Agent Skills format working across a dozen agents, and that bet is aging well. Skills you write once follow you if you switch tools.
Where I'd be careful
Token budgets still apply. Skills are loaded context. Install eight of them and you've reconstructed the bloated-system-prompt problem skills were meant to solve, just distributed across files. My working rule is the same one I apply to choosing which Claude Code skills are worth installing: every installed skill must fix a mistake your agent actually makes. Speculative installs are context debt.
No composition semantics. Skills don't declare relationships to each other. If one skill's conventions build on another's, you have to know that and install both. The registries will need something like dependency hints eventually; today it's tribal knowledge.
Quality variance is real. The review gate catches unsafe skills, not mediocre ones. The distribution of community skill quality looks exactly like the distribution of community npm packages circa 2014, which is to say: wide.
How I'd start today
Pick one project where Claude repeatedly ignores a convention you care about. Search skills.sh for that specific domain, read the top result's markdown end to end, and install exactly one skill. Work with it for a few days before adding a second. If nothing in the registry fits, write your own; a focused skill takes about an hour, and it will beat a generic one for your stack every time. My roundup of the skills, plugins, and CLIs I actually keep installed shows what survived that filter on my machine.
The larger picture: skill registries are becoming the package managers of agent behavior, and skills.sh is currently the best-executed open version of that idea. Distribution is now a solved problem. Curation isn't, and that's where the next year of this ecosystem gets decided.
If you'd rather start from a vetted shortlist than an open firehose, browse my agent skills marketplace. Every one of the 53 listings links its source repo, names its author, and says exactly what it changes, because that's the metadata I wish every registry made mandatory.
