An engineer looking to speed up a team’s workflow in Claude Code, the coding agent built on Claude, powered by Anthropic, once installed a well-starred skill collection, the kind that sits at the top of every “best skills” roundup. Forty-seven skills went in, and testing each one against Claude Code with no skills installed showed that forty of them made the output worse. Popularity had told the engineer nothing about whether a skill would help.
The binding constraint on skill adoption was never the marketplace. It’s an evaluation. That evaluation runs in four steps:
- Classify the skill: capability uplift or encoded preference
- Check the trust tier: official, pinned-community, unaudited-community, or proprietary
- Check the adoption signal: scope discipline and activation rate
- Check install discipline: what makes an install durable, not just fast
That instinct isn’t new at Zartis. The same discipline that catches scope creep in day-to-day Claude Code use: confirm the boundary before acting, review before shipping, is what already gets applied, formally, to home-grown skills before they enter a shared workflow. An internal proposal for a shared Claude Code workshop skills library, for instance, already gates every internally-built skill through review before it’s merged. This is the proprietary tier below: skills with no external marketplace signal to lean on.
When to Build a Skill vs. Borrow One
Skills are filesystem-based resources that give Claude domain-specific expertise: workflows, context and success criteria a general-purpose agent doesn’t otherwise have. The first filter, before evaluating any specific candidate, is classification. A skill is either a capability uplift, meaning it genuinely teaches Claude something it couldn’t otherwise do, or an encoded preference, meaning it captures a team-specific convention, workflow or success criterion the base model has no way to know about. Encoded-preference skills are the stronger build candidates: they survive model upgrades better, because they’re not competing with the model’s own growing baseline competence, only constraining it to a house style. Done well, they become part of a team’s operating capability rather than an isolated tool bolted onto a workflow. Capability-uplift skills are better borrowed from a trusted source if one already exists, since building genuinely new capability from scratch duplicates work the ecosystem may have already solved.
The decision rule is blunt: if a team can’t state the success criterion a skill adds that the model doesn’t already know to care about, it isn’t worth building or installing.
Official, Community and Proprietary Skills Aren’t the Same Risk Category
Once a team knows what kind of skill it needs, the next question is where it’s safe to get one. Four tiers, in descending order of external trust:
- Official: listed in Anthropic’s own marketplace, whose name Claude Code reserves so no other catalogue can pose as it; the strongest provenance signal available, though most entries come from partners and other authors, not Anthropic.
- Pinned-community: third-party plugins submitted to Anthropic’s community marketplace, nearly all pinned to a fixed commit, but the code itself is still third-party.
- Unaudited-community: the long-tail catalogues, no centralised review of any kind.
- Proprietary: no external review at all, but full context on what the skill is for and who owns it; trust has to come from a team’s own code review, not marketplace provenance.
Anthropic runs two of these tiers directly: an official marketplace, and a community marketplace of third-party plugins submitted to Anthropic, nearly every one pinned to a specific commit SHA. Beyond both sits a long tail of independent, non-Anthropic catalogues with no centralised review at all: one such marketplace alone lists 2,984 marketplace-visible skills by its own labelled count, plus 471 plugins and 347 agents, a concrete, checkable scale reference for a single third-party catalogue.
That long tail is where the risk concentrates. A security audit of 3,984 skills, drawn mainly from ClawHub with a curated set from skills.sh, found that 36.8% carried at least one security flaw of any kind, and 13.4% carried a critical one. Anthropic’s own marketplaces narrow this exposure but don’t eliminate it. Claude Code’s install warning is explicit: “Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended.” Anthropic’s Skills documentation recommends treating skill installation “like installing software.”
Trust tier answers whether a skill is safe to run. It doesn’t answer whether it’s worth running.
What the Most-Adopted Skills Get Right
By GitHub stars, the community-built “Superpowers” methodology has cleared 243,000+ and Anthropic’s own official skills repository 157,000+. Both are narrower and more directive in scope than most collections.
Scope discipline shows up in the numbers directly. Measured activation rates vary widely across studies, from 50% to 77%, and one controlled study found that phrasing explains much of the gap: directive descriptions reached 100% activation, against 37% for passive summaries. MacAgentBench recorded 89.4% success on skill-covered tasks against a 55.9% no-skill baseline, but on tasks outside a skill’s coverage, the skilled agent underperformed that baseline for five of eight models tested. A skill scoped too broadly carries a measurable cost outside its lane, not just a missed benefit inside it.
The 2-Minute Install Pattern That Actually Sticks
None of this is hard to check once a skill has cleared classification and trust-tier evaluation. Installing it is genuinely fast: add the marketplace once (/plugin marketplace add <source>), then install the specific skill or plugin (/plugin install <name>@<marketplace>), a two-command flow. Each install also asks for a scope: user (every project), project (the whole team, via .claude/settings.json) or local (this repository only), so the same fast flow works whether one engineer is trying something out or a whole team is adopting it.
That speed is exactly why unfiltered adoption creates real exposure: there’s no friction forcing evaluation before a skill enters a shared workflow. What makes an install durable rather than dead weight is three checks run before the two commands, not after: confirm the classification, confirm the trust tier and, if activation matters, confirm the skill’s description is written as a directive routing rule rather than a passive summary. Teams rolling a skill out beyond one engineer should also treat it like any other shared dependency: reviewed, versioned and revisited when the underlying model changes, since Claude Code itself surfaces plugins that haven’t been used recently as candidates for removal.
Installation was never the hard part. The forty skills that made things worse were two minutes away too. What separates a skill that compounds a team’s velocity from one that quietly taxes every future session isn’t where it came from. It’s whether anyone checked.
Conclusion: Treat Skills Like Dependencies
The real problem. Finding skills isn’t hard; choosing the right ones is. The answer comes down to three simple checks before you install: classify what the skill does, verify where it came from, and write its description as a clear directive. In one study, that last step alone took activation from 37% to 100%.
For engineering leaders. When one person installs a skill at project level, everyone on the team gets it. That’s a shared decision, and it needs one simple approval process. Here are three things to do:
- Make a tier policy. Decide in advance: official skills get a light review, community skills a closer one, and everything else a full code review.
- Assign an owner to each skill. One person stays responsible and watches it when the model updates.
- Set a removal trigger. Claude Code already flags plugins that haven’t been used recently. Review those regularly and remove what nobody uses.
The bottom line. There are thousands of skills out there. The real shortage isn’t supply, it’s judgment. Teams that build this habit once, with a quick approval gate, turn skills into real working tools.
Author
Buğra Sitemkar is a software engineer at Zartis specialising in Microsoft Stack and Azure. He’s passionate about applied AI and building GenAI tooling. He occasionally moonlights as a hardware hacker.
