To roll out Claude skills across a team you settle four things: who owns each skill, who read it before anyone used it, which version production is pinned to, and how many are active at once. Anthropic documents all four. Handing them out is still your job.
This is for an operations manager or COO who has one skill working and now has to turn it into something a team depends on. The product name is Agent Skills; in running text it is a skill. A skill is a folder with an instruction file that Claude loads by itself when the task calls for it, and how a skill works covers the mechanics. This article is about the management around it.
One distinction first, because this topic invites a muddle: a skill is a file, while what a person needs to be able to do is a capability, and that is a separate question.
Who manages a team’s skills?
One named person per skill, written down where anyone can find it. Anthropic’s enterprise guidance asks for an internal registry with an owner field: the team or individual responsible for maintenance [S-081]. Not a role in a policy. A name next to a folder.
That skill owner carries more than a label. Every update counts as a new deployment that needs a full security review [S-082], and the registry records when the skill was last evaluated and with what result [S-081]. The same pattern decides whether an automation survives its first month: who owns an automation after launch. In a 25 to 200 person company that is one person per domain, not a committee.
Who reviews a skill before anyone uses it?
Somebody other than the author. Anthropic puts it as separation of duties: skill authors should not be their own reviewers, and both a security review and an evaluation suite should be required before approval [S-073]. Review before use is the whole agreement, and in most teams it is the one nobody made.
What that reviewer looks for is documented as a risk table: seven indicators with the weight the documentation gives each [S-071]:
| Indicator | What you look for | Weight |
|---|---|---|
| Code execution | scripts in the skill directory (*.py, *.sh, *.js) | high: scripts run with full environment access |
| Safety bypass | instructions that work around safety rules | high |
| MCP-server references | tools the skill reaches through another server | high: extends access beyond the skill itself |
| Network access patterns | URLs, fetch, curl, requests | high: potential data exfiltration vector |
| Credentials | keys or tokens hardcoded in a file | high |
| File paths | paths outside the skill directory | medium |
| Shell and file operations | instructions to invoke bash or file operations | medium |
The full checklist runs to eight steps [S-072]. For a smaller team the realistic core is the first three: read every file in the skill directory, run the scripts in a sandboxed environment and verify their behaviour matches the stated purpose, and check for hardcoded credentials. The rest is the same reading with a sharper eye: adversarial instructions, network calls, invoked tools and commands, external URL destinations, and data exfiltration patterns [S-072].
The hard line is Anthropic’s: never deploy skills from untrusted sources without a full audit, because a malicious skill can execute arbitrary code, access sensitive files or transmit data externally, and installation deserves the same rigour as installing software on production systems [S-074]. Read every bundled file, not only SKILL.md [S-062].
In a team of five there is no second reviewer with the right title. The workable version: whoever did not write the skill reads it, even if that is the founder.
What do you test before a skill goes into production?
Five things, and the one people skip is whether the skill stays quiet when it should. Anthropic names five evaluation dimensions before production, each with an example failure [S-076]:
| Dimension | Documented example failure |
|---|---|
| Triggering accuracy | the skill triggers on every spreadsheet mention, even when the user just wants to discuss data [S-076] |
| Isolation behavior | the skill references files that do not exist in its directory [S-076] |
| Coexistence | the new skill’s description is too broad, stealing triggers from existing skills [S-076] |
| Instruction following | Claude skips validation steps or uses the wrong libraries [S-076] |
| Output quality | generated reports have formatting errors or missing data [S-076] |
Around that sits the evaluation suite: three to five representative queries per skill, covering cases where it should trigger, cases where it should not, and ambiguous edge cases, tested across every model the organisation uses because effectiveness varies by model [S-077].
That middle category is the point: teams test whether the skill works and stop there. Nobody tests the request that must not wake it up, and that is what makes colleagues distrust the tool.
Which version does production run?
The one you pinned, or else whatever was uploaded last. If you omit the version field, requests use the latest version, so a new version uploaded by anyone in the workspace immediately changes what production agents run [S-082]. That is the reason for version pinning. Not tidiness.
The rest follows. Every update is a new deployment with a full security review, the previous version stays as a fallback, checksums of reviewed skills get verified at deployment time, and the repository uses signed commits [S-082].
How many skills can be active at once?
Fewer than the folder count suggests, and at most twenty per request. Each skill’s name and description competes for attention in the system prompt; with too many active, Claude may fail to select the right skill or miss relevant ones entirely [S-079]. API requests support a maximum of 20 skills each [S-079].
So the number of active skills is a design decision, not an inventory. If a role needs more than the limit, merge narrow skills or route requests by task type to different sets [S-079]. The sequence matters: start narrow and workflow-specific rather than broad, and merge into a role-level bundle only when the merged skill’s evaluations confirm equivalent performance to the skills it replaces [S-080]. The documented example merges formatting-sales-reports, querying-pipeline-data and updating-crm-records into one sales-operations [S-080].
And the field that decides which skill gets picked is the description: write it in third person, because it is injected into the system prompt [S-063].
How do you share a skill with your team?
Through your own repository, because the product does not do it for you. Flat, as the documentation reads on 11 October 2026:
- Custom skills do not sync across surfaces. Surface is the documentation’s word for the environments Claude runs in: claude.ai, the Claude API and Claude Code. A skill uploaded to one is not automatically available on the others, and Claude Code skills live on the filesystem, separate from both [S-059].
- In claude.ai a custom skill belongs to the individual user and each team member must upload it separately. There is no centralised admin management and no org-wide distribution of custom skills [S-060].
- On the Claude API distribution is workspace-wide, which is a workspace, not an organisation [S-083].
- Usage analytics are not currently available through the Skills API. To know which skills went into which request you implement application-level logging yourself [S-078].
- Automatic security scanning of custom skills exists for Claude Enterprise organisations in claude.ai and Claude Cowork. A skill that fails the scan, or whose scan has not finished, is blocked; one that passes with a warning stays usable behind a caution notice. Scanning does not cover the Claude API, skips skills that already existed when it was switched on, and is unavailable under certain data configurations (CMEK, zero data retention, HIPAA readiness). It complements the review checklist, it does not replace it [S-075].
The documentation draws the conclusion itself: keep skills in Git as the single source of truth, for history, review through pull requests and rollback, and build your own synchronisation process if you use more than one surface [S-083]. Claude Code is the surface where that repository is also the distribution channel, as in Claude Code for business.
What belongs in a skill register?
Five fields, one row per skill [S-081]. Example row, to be replaced with your own:
| Purpose | Owner | Version | Dependencies | Last evaluated |
|---|---|---|---|---|
| Builds the monthly management report from the CRM export | Operations lead | pinned in the request, previous version kept as fallback | the CRM MCP-server and the export folder | 4 October 2026, triggered correctly on all five test queries |
No template and no form. A table in the repository next to the skills, so the registry moves when they move. An empty field is the finding: no owner or no evaluation date means not ready for a team.
How WeAdapt manages its own skills
The studios WeAdapt runs on internally are built from skills in a Git repository, and the agreement is the four questions above. One owner per skill. Every change arrives as a pull request that somebody other than the author reads. Production runs a pinned version, the repository is the source of truth rather than any one surface, and per project the number stays small.
What that agreement fixes is responsibility, not speed: who may change the file, who checks it, and what production may run today. Whether your team can carry it is a capability question, which is what a training or workshop is for. A method that earns its own entry point stops being a skill and becomes a custom AI tool that WeAdapt builds and hands over.
Frequently asked questions
Can an administrator install a skill for the whole team? Not in claude.ai. A custom skill there belongs to the individual user, each team member uploads it separately, and there is no centralised admin management or org-wide distribution [S-060]. On the Claude API distribution is workspace-wide [S-083]; in Claude Code you share through the project repository [S-060].
How do we see which skills are actually being used? By logging it yourself. Usage analytics are not currently available through the Skills API, so the documentation points to application-level logging to track which skills are included in requests [S-078]. Until then, adoption is an impression rather than a measurement.
Does Claude check our own skills for safety? Only in part, and only for some customers. Claude Enterprise organisations can enable automatic scanning of custom skills in claude.ai and Claude Cowork, where a failed or unfinished scan blocks the skill [S-075]. It does not cover the Claude API, skips skills that predate it, and complements rather than replaces the review checklist [S-075].
Wondering which method in your company deserves a skill, who should own it and what review it needs first? WeAdapt builds the system and hands it over with the agreement written down. What the handover includes is in the FAQ, or book a call.