skills.sh Crossed 1 Million Agent Skills: What Teams Actually Install

Vercel’s State of agent skills report says the skills.sh registry crossed one million agent skills with nearly 280 million installs in seven months, a first-million pace the company contrasts with GitHub’s 27 months to a million repositories. Every figure in that sentence is self-reported by the registry’s operator, and installs count acquisitions, not users or outcomes. Even so, the numbers force a real decision: how should a team encode its judgment for agents, and when is it safe to standardize on a stranger’s skill file?

One million skills in seven months, and what that pace actually signals

Anthropic introduced Agent Skills in October 2025. Vercel launched the skills.sh registry roughly three months later, in early 2026, and the registry reached one million listings within seven months of that launch, according to Vercel’s report. The same report lines up the comparison: GitHub took 27 months to reach one million repositories, Apple’s App Store just over five years to reach one million apps, and npm more than nine years to reach one million packages.

That ordering deserves a skeptical read before it impresses anyone. A skill is a portable instruction file, far cheaper to author than an application or a published package, so the supply side of this registry was always going to fill faster than its predecessors. The pace comparison is vendor framing, and it measures listing creation, not vetted quality. What the pace does signal, without any vendor gloss, is that publication friction is near zero while install volume is enormous. When a distribution channel grows this fast, no operator can review listings at the rate they arrive. The review burden moves to the team doing the installing, which is the fact that should drive your policy.

What teams actually install

The more useful part of the report is not the milestone but the distribution. What gets listed and what gets installed are different populations.

On the listing side, Vercel reports that more than half of skills.sh entries teach software engineering, agent workflows, data, infrastructure, or security, with software engineering alone about a quarter of listings. On the install side, demand is flatter and less developer-centric: no category draws more than a fifth of installs, software engineering leads at 18%, agent workflows at 15%, and business operations and writing near 11% each, per Vercel’s report.

The per-skill averages sharpen the picture. Business operations skills average 74% more installs than the overall mean, per Vercel, writing and documents 50% more, and cloud and infrastructure 42% more. Cross-industry skills account for 66% of classified listings but 87.5% of installs, averaging 3.6 times as many installs per listing as industry-specific ones. A reasonable inference from that gap: teams reach for skills that transfer across domains, the reusable know-how a general agent lacks, rather than narrow trade knowledge they may already hold. That is inference from aggregate shares, not a surveyed motive, and the category classification underneath it is methodology-unaudited.

Then there is concentration, the single most decision-relevant statistic in the report:

Per Vercel’s own figures, what gets installed is overwhelmingly the behavior of a thin top slice. The honest reading of one million skills is that the registry offers a few hundred de facto standards and a nearly unreviewed long tail. If your team installs from the tail, you are almost certainly among the first to ever run that file, which is exactly where the audit burden lands hardest.

Skills, repo rules, or wired MCP tools: match the encoding to the job

The registry numbers matter only after a prior decision: which mechanism should carry a given piece of team judgment at all. There are three realistic options, and they are not interchangeable.

Distributable skill files package reusable know-how as instructions an agent loads on demand. They travel well across repos and teammates, which the skills.sh install data confirms is their draw. Their weakness is update propagation: an install is a copy, and the vendor report says nothing about how or whether installed copies track upstream changes. Writing a skill once beats re-explaining per repo only if updates reach installed copies as cleanly as the original install did. Groundy’s comparison of agent skill systems found that portability across runtimes is the other place this mechanism breaks down.

Wired MCP tools connect the agent to live systems rather than teaching it about them. The Model Context Protocol was introduced by Anthropic in November 2024 and donated in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, per Wikipedia’s MCP article. The MCP project itself is an open-source, Linux Foundation-hosted effort, which lowers the risk that the standard strands your integration. The risk sits in the connection, not the governance: an April 2025 security analysis concluded MCP has multiple outstanding issues, including prompt injection and poisoned tools that exfiltrate data through other connected tools. When the question is whether a given tool server earns its place, Groundy’s keep, fix, or drop test for MCP servers applies the same per-job logic.

Repo-local rules (AGENTS.md and equivalents) are artifacts you own, versioned and reviewed with the code they govern. They suit fast-changing norms: house style, security invariants, output constraints. Two honesty notes here. First, the sources cited in this article include no measured evidence about rules files, so this column of the framework is reasoning, not data. Second, rule loading is itself a behavior to verify: Groundy recently covered testing whether agents actually load AGENTS.md, because an unread rule file is indistinguishable from a missing one.

The table is a framework, not a verdict. Most teams end up with all three, and the skill-versus-rules boundary is the one worth drawing deliberately: if the knowledge changes monthly, a registry-pulled copy will drift.

Why install counts are not endorsements

The strongest caveat in this story comes from the vendor. The report states: “Install figures use aggregate registry counters. They do not represent unique people or necessarily independent choices.” Combined with the concentration data, that means the registry’s 280 million installs could include repeat installs, automated pulls, and CI-driven fetches, all counted identically to a deliberate human decision.

Three distortions follow. First, installs measure acquisition, not usage, retention, or task success; a skill installed and abandoned counts the same as one run daily. Second, popularity compounds mechanically: a skill featured in an agent’s default suggestions or a framework’s starter template accrues installs that reflect placement, not evaluation. Third, all of it is self-reported by the registry’s operator; the report cites no independent audit, and the category shares rest on a classification methodology the report does not open to inspection. Groundy has seen the same failure pattern on the tool side, where registries propagate self-reported descriptions that agents then trust. The correct mental model for skills.sh is an acquisition channel: excellent for discovery, silent on quality.

One more limit: nothing in the vendor report or the security research cited above measures how updates propagate to installed copies, or says anything about rules files like AGENTS.md despite that mechanism’s place in the framework; the April 2025 MCP findings concern connected tools and servers, not skill files. Where this article draws conclusions beyond the aggregates, about why cross-industry skills dominate installs or what growth implies for review burden, those are inferences from one self-interested dataset, and they should be priced accordingly.

The pre-install trust check

A skill file is instructions that execute with your agent’s privileges, so the rational posture is to audit it like a dependency, not like documentation. The MCP findings motivate this without measuring it: prompt injection and poisoned tools describe wired tool servers, a different attack surface from instruction files, and the vendor report cites no independent security audit of any skills.sh listing. Absence of evidence is not evidence of safety; it is an unpriced risk you inherit on install.

A workable pre-install check, before any third-party skill becomes team standard:

1. Read the entire file. Skills are short enough that full review is cheap. Anything that instructs the agent to fetch remote content, exfiltrate context, or disable safeguards ends the review.
2. Prefer the top slice with eyes open. The 375 skills drawing 62% of installs at least carry the scrutiny that popularity attracts; tail listings have neither scrutiny nor track record. Popularity is a weak signal, but total obscurity is a weaker one.
3. Sandbox the first run. Vercel Sandbox is an ephemeral compute primitive designed to run untrusted or user-generated code, and ephemeral environments of that kind are the right place to watch what a new skill actually does before it touches a real repository.
4. Gate updates like installs. Because installed skills are copies, decide who re-reviews when the upstream file changes. Groundy’s coverage of GitHub CLI’s skill command landed on the same posture: treat skills as dependencies with a review pipeline, not as configuration you set once.

A team policy for adopting agent skills

The practical verdict: treat skills.sh as an acquisition channel, not a curation signal. Match the mechanism to the job first: distributable skill files for reusable know-how that changes slowly, wired MCP tools for live system access (with the injection risk audited server by server), and repo-local rules you own for norms that move with the code. Then gate standardization on your own review, because the registry’s growth rate guarantees the operator has not done it for you. Before any third-party skill becomes default, read it in full, run it in a sandbox, and assign an owner for re-reviewing updates. And when you justify the decision internally, leave install counts out of it: by the vendor’s own admission, they measure acquisition, and acquisition was never the thing you needed to trust.