Agent skills are portable business workflows that any employee or agent can pick up and execute, making them essential for AI business. That’s also why they’re spreading faster than anyone can vet them. So Arcade.dev built SkillBench, the open index that scores agent skills across six weighted dimensions and rolls each into a letter grade from A to F.
We introduced SkillBench and the scoring method in our launch post. Now that over 39,000 skills have been scored, we wanted to dive into the data for some key takeaways that go deeper than the launch numbers alone.
Here are the three takeaways that matter most if you build with skills.
1. A passing grade is not a safety guarantee
73.7% of the visible catalog carries a risky safety score, and that’s after the worst offenders are already gone. 7,034 skills tripped the hard safety gate and were quarantined before they could ever be listed.
SkillBench measures how much damage a skill could do if something went wrong, and the answer for most skills is “quite a lot.” A skill that can execute code, touch secrets, or take irreversible actions carries real risk even when its author meant well. So an elevated-risk score reflects blast radius, not proven malice, because that’s the dimension that best reflects real business risk.
For developers and the enterprises they build for, the implication is that a badge tells you a skill is well-formed, but that doesn’t mean it’s safe to run unsupervised. Safety is a runtime property. You contain it where the skill acts by governing what an agent is allowed to do when it acts on a skill.
2. The tool boundary is where describing becomes acting
Tool-boundary scores below 80 apply to 32.1% of the catalog, roughly 12,500 skills, and 5,007 of those (12.8%) are seriously weak, scoring below 60. This is the dimension that governs what a skill is allowed to do, as opposed to what it claims to do.
The pattern underneath the number is the core problem with skills as a format. A skill is supposed to describe a workflow, but the moment it starts reaching for credentials, hitting the network, or writing files, it has crossed from describing into acting, often without declaring it. A weak tool boundary is exactly that blur: capability that isn’t scoped, isn’t declared, and isn’t checked against what the user actually permitted.
This is the Arcade thesis in one statistic. When a skill needs to take an action, that action belongs in a governed tool layer, not in free-floating skill text. Route it through declared tools where the agent can only do what both it and the user are permitted to do, enforced at the moment of the call.
So the difference between a skill that says it edits one document and one that quietly reaches into a credential store comes down to where that call is governed. That’s the difference between a productivity gain and an incident. The tool boundary is where you draw that line, and today two-thirds of skills draw it well while many don’t draw it at all.
3. Popularity does not predict quality
Among the 600 most popular, high-star skills, 62% are graded C or below, slightly worse than the full corpus, where 58.4% are C or below and only 41.6% earn a recommendable A or B. Half of all scored skills (49.8%) also have low provenance, meaning weak signals of ownership, maintenance, and traceability.
What this says about skills is that adoption and trust are different measurements, and the market is conflating them. A skill can rack up hundreds of thousands of stars on the strength of its author’s reputation while individual entries in the same collection score a D on triggerability or a 48 on provenance.
Anyone building on skills cannot trust a skill by inspection, and they certainly can’t trust it by star count. Trust has to come from somewhere the ranking can’t reach: a governed runtime that manages authorization and execution regardless of how popular the skill is.
Plenty of popular skills also do score well, so this isn’t an argument against adoption. It’s an argument for verifying before you install.
If you’re deploying agents…
The through-line across all three takeaways is that the trustworthiness of a skill lives at runtime. Safety is contained where the skill acts. The tool boundary is enforced where describing turns into acting. And quality has to be verified independent of how many people already installed it.
If you’re choosing skills, filter by grade and read the source on anything below a B. If you’re publishing them, score your own before your users do. And if you’re deploying agents at scale, assume that the skills your team installs will keep multiplying faster than any review process, and put the controls where the actions happen.
