How to Roll Out and Govern Claude Skills Across Your Firm

The first three Skills a firm writes look after themselves: the people who wrote them are the people using them. The trouble starts around the tenth, when colleagues who did not write them rely on them, nobody is sure which version is current, and a Skill written in March quietly encodes a process that changed in June. This article covers how a firm creates, approves, shares, maintains and retires Claude Skills once more than a handful of people depend on them.

If you are still working out what a Skill is, start with our explainer on what Claude Skills are and where they pay off. This piece assumes you know, and asks how to run them.

Give every Skill a named owner

A Skill is a procedure written down, and like any procedure it drifts unless someone is responsible for it. Anthropic's guidance for deploying Skills across an organisation recommends an internal registry recording each Skill's purpose, owner, current version, dependencies and last evaluation date. That is a spreadsheet, and it is the most useful governance artefact you can create on day one.

The owner should be whoever owns the underlying business process, not whoever is good with Claude. The finance lead owns the month-end Skill because the finance lead knows when month-end changes. Anthropic also recommends separating author from reviewer. In a firm of fifty that can be a second reader, but a named one.

Capture the procedure so it loads at the right moment and survives reality

Two things decide whether a Skill helps. The first is its description. Claude carries only each Skill's name and description into a conversation and reads the full instructions when a request matches. Anthropic's documentation is explicit: "The description is what Claude matches your request against when determining whether to trigger the Skill, so it must say both what the Skill does and when to use it." A description that says "handles proposals" fires too rarely. One that lists the phrases people actually use ("quote", "SoW", "scope this") fires when it should. Write it last, after watching how people ask for the job.

The second is what goes in the body. The temptation is the happy path. The valuable content is the failure you have already hit: the step that looks like it worked when it did not, the default that is destructive, the check everyone skips. A Skill that encodes only the happy path is a tidier prompt. One that encodes the mistakes is institutional memory that does not leave when a person does. Where a step can be done deterministically, bundle a script and have the Skill call it. Anthropic notes that scripts run without their code entering the conversation, so a validation script costs almost nothing.

What this looks like in practice: our own eight Skills

SpotDev runs its marketing operations on eight Claude Skills: publishing to our website, managing redirects, updating the structured data behind our integration directory, producing the newsletter and maintaining its lists, performance reporting, deciding which ranking pages to rewrite, and building content clusters. Each was written after something went wrong, because a mistake is the cheapest way to find out where a procedure needs to be explicit rather than assumed.

Three examples. A routine update to one field on a data record in our CMS wiped every other field on that record and dozens like it, because the underlying update replaced the whole record rather than merging into it. The system reported success. The Skill that now governs those writes reads the current record, merges only the intended change, takes a backup, and runs as a dry run by default so the diff is read before anything is applied. The care moved from the person into the procedure.

Our newsletter Skill treats content edits and recipient-list edits as two separate steps with a read-back check between them, because changing both in one request once silently dropped our do-not-send suppression list. Again the API reported success, so the Skill now says in so many words that a success response is meaningless here and the stored value is what counts.

Our publishing Skill insists on fetching the live URL after publishing rather than trusting the record, because a post once reported itself published while the page returned a not-found error. It also carries a dated log of every trap found since, kept by one rule: when a new failure bites, it is written into the Skill in the same session. We have not tried to measure the time these Skills save, so we make no claim about it.

Review before anything is rolled out

A Skill is instructions plus, often, code that Claude runs with whatever access the user has. Anthropic's security guidance is blunt: "Use Skills only from trusted sources: those you created yourself or obtained from Anthropic." It continues: "a malicious Skill can direct Claude to invoke tools or execute code in ways that don't match the Skill's stated purpose." For anything from an unknown source it says to "thoroughly audit it before use", and describes the audit: "Review all files bundled in the Skill: SKILL.md, scripts, images, and other resources. Look for unusual patterns such as unexpected network calls, file access patterns, or operations that don't match the Skill's stated purpose." Skills that fetch external content get a specific warning, because fetched content may itself carry instructions.

The risk has materialised, and it is worth being precise about where. In February 2026 the security firm Snyk published research it called ToxicSkills, having scanned 3,984 skills from two third-party marketplaces, ClawHub and skills.sh. It found 13.4% contained at least one critical-level security issue, 36.82% had a flaw of some severity, and 76 were built for credential theft, backdoor installation or data exfiltration. Those marketplaces are not run by Anthropic, whose own distribution is a public GitHub repository and, on Team and Enterprise plans, organisation-level provisioning. The lesson is that an open marketplace behaves like every other software supply chain, and a Skill is software.

The practical review, drawn from Anthropic's enterprise checklist: read every file, run any scripts in a sandbox, search for network calls and hardcoded credentials, list every tool the Skill asks Claude to invoke, and look for instructions telling Claude to ignore rules or hide actions. Apply it to internal Skills too. A colleague means well, but their Skill can still contain mistakes.

What the Team and Enterprise admin controls do, and what they do not

A custom Skill uploaded to claude.ai on a standard plan belongs to the person who uploaded it. Anthropic's documentation says such Skills "are not shared organization-wide and cannot be centrally managed by admins." Governance at scale therefore means a Team or Enterprise plan, where Anthropic's help centre article on provisioning Skills documents these controls:

• Organisation-wide provisioning. Owners publish an approved Skill so it appears for everyone. Only owners can add or remove organisation-wide Skills.
• A code execution prerequisite. Skills need code execution enabled in the organisation policy. If it is off, Skills do not work.
• A publishing policy. "Requires review" means an owner approves each submitted Skill before it reaches the organisation library. "Open" publishes submissions without review. "Off" removes the option.
• A switch for user-created Skills, so staff cannot create or upload their own while provisioned ones remain available.
• Security scanning, Enterprise only. Custom Skills uploaded or edited in claude.ai and Claude Cowork are scanned, and a Skill that fails, or whose scan has not finished, is blocked.
• Audit logging of sharing. Sharing events appear in the audit log and Compliance API as role_assignment events, showing who shared a Skill, with whom, and at what scope.

Three limits matter. Scanning does not cover Skills uploaded through the Skills API or Claude Console, Skills already present when it was switched on, or organisations using certain data-handling configurations such as zero data retention. Anthropic says it complements the manual checklist rather than replacing it. The audit log records that a Skill was shared, not what it contained, so only your own version history shows what a Skill instructed Claude to do at a given time. And custom Skills do not sync across surfaces: a Skill uploaded to claude.ai is not available through the API, and Skills in Claude Code are separate files again, so the registry must say which copy is authoritative.

Version Skills like software, because they are

Anthropic recommends keeping Skill folders in Git as the single source of truth, so every change has a history, a reviewer and a rollback. For Skills used through the API it recommends pinning production to a specific version, because otherwise the latest upload immediately changes what production agents run, and treating every update as a new deployment with a full security review. That is the right standard for any Skill that touches customer data or acts in a business system.

Keeping a Skill current comes down to two habits. When a step fails or a system changes behaviour, update the Skill in the same session, dated. And at a fixed cadence, have the owner reread it and ask whether every instruction is still true. Anthropic suggests rerunning a small evaluation set (requests that should trigger the Skill, some that should not, a few ambiguous ones) to catch drift as workflows and models change.

Retire what has gone stale

An unused Skill is not free. Every Skill's description sits in the system prompt of every conversation, and Anthropic warns that with too many active, Claude "may fail to select the right Skill or miss relevant ones entirely." A stale Skill is worse than an unused one, because it fires confidently on a process that no longer exists.

Deprecate a Skill when its workflow is retired, when it repeatedly fails evaluation, or when its owner leaves and nobody claims it within a set period. Remove it from the organisation library and the registry rather than leaving it switched off, and consolidate narrow overlapping Skills into broader ones once patterns emerge. Keep the retired folder in version control for the history.

Write Skills to the open standard, not to one vendor

On 18 Dec 2025 Anthropic published the Skills format as an open standard at agentskills.io, and other vendors have since documented support for the same SKILL.md format: OpenAI's Codex, GitHub Copilot (whose documentation calls the specification "an open standard, used by a range of different AI systems"), Cursor and Google's Gemini CLI. Support is concentrated in developer tools and no CRM or business application platform supports the format, so treat portability as protection against lock-in rather than a promise that one Skill runs everywhere your staff work.

It still changes how you write. Keep the procedure, the checks and the failure history in plain language that assumes nothing about which model is reading it, and keep anything vendor-specific in a separate section or a script. We help firms choose between Claude, OpenAI and other platforms on fit, and a client's procedures should not be hostage to that choice.

Where to start

Pick one process that is repetitive, has a known failure mode and a clear owner. Write the Skill with that owner, have a second person review it against the checklist above, publish it with "Requires review" as the standing policy, and add a row to the registry. Add the second Skill only when the first has been used by someone other than its author.

If you would like help designing that library, or building Skills that connect safely to your business systems, our Claude implementation service covers both. Our guide to Claude AI agents for business shows where Skills sit alongside Projects, connectors and agents, and our AI governance framework for UK businesses covers the policy layer above all of this.

Frequently asked questions

Who should own a Claude Skill?

The person who owns the business process it encodes, not the person most fluent with Claude. Anthropic recommends a registry recording each Skill's purpose, owner, version, dependencies and last evaluation date, and separating the author from the reviewer.

Can an admin see what a Skill contains from the audit log?

No. On Team and Enterprise plans the audit log and Compliance API record sharing events (who shared a Skill, with whom, and at what scope), not the Skill's contents. Only your own version history shows what a Skill instructed Claude to do at a given time.

Does Anthropic scan Skills for malicious content?

Only on the Enterprise plan, only when the organisation turns it on, and only for custom Skills uploaded or edited in claude.ai and Claude Cowork. It does not cover Skills uploaded through the Skills API or Claude Console, or Skills already present when scanning was enabled. Anthropic describes it as a complement to manual review.

Will a Skill written for Claude work with other AI tools?

Possibly, for developer tools. Anthropic published the format as an open standard in December 2025, and OpenAI Codex, GitHub Copilot, Cursor and Google Gemini CLI document support for the same SKILL.md format. No CRM or business application platform supports it, so write vendor-neutrally and treat portability as insurance.