In my cohorts, building a Claude skill is the quick part. Running dozens of them across a team, fast, without losing control, is where teams get stuck.
It’s tempting to see speed, scale, and governance as a trade-off: move fast and lose track of what’s running, or lock things down and slow everyone down. In my experience, you don’t have to choose. Treat skills the way a well-run business treats its playbooks: one approved version, a named owner, and every update reaching everyone at once.
That’s how I run nearly 100 skills and 17 agents across my business. Every skill I change gets a version number before anyone else runs it, and I can account for every one. The payoff is a portfolio of skills that accelerates the whole business, with governance intact.
TL;DR
Speed, scale, and governance can coexist. Releasing skills, rather than sharing files, gets all three.
Shared skill files drift. Copies multiply, get edited, and nobody can say which version produced an output.
One source, one release. Skills change in one place and reach everyone as a versioned plugin.
The version number is the contract. An edit is a patch, a new skill a minor, a removal a major.
I’m showing all of it live, free, this Friday, November 6.
Why copies drift
Someone on a team builds a good skill. A teammate copies the file. Someone else improves their copy.
A month later, three versions are in use. Which one wrote this morning’s client reply? Who changed it last? What is it allowed to touch? Nobody can say. The hard part is that nothing breaks loudly. Each copy keeps working, so the drift stays invisible until an output goes wrong.
When it’s only you, that’s a nuisance. Once a team depends on those skills, it’s a governance problem.
The pattern: one source and a release
My skills and agents live in one source folder on GitHub, which keeps a record of every change. That’s the skill source: the only place a skill is ever edited.
When a change is ready, it’s released to a separate plugin folder. That one holds finished work only, and it’s what gets installed. A plugin is a package of skills and agents Claude installs in one step. A marketplace is the GitHub location your team installs it from.
The split matters because the people using your skills don’t need your skill source. They need what you’ve finished, at a known version, and nothing half-built.
Try this (10 minutes). List where your team’s most-used skill lives today. Count the copies.
The version number is the contract
Every release gets a version, and the number says what kind of change it was:
Patch (1.1.0 → 1.1.1). A skill was edited.
Minor (1.1.1 → 1.2.0). A skill was added.
Major (1.2.0 → 2.0.0). A skill was removed, so someone who relied on it loses something.
A teammate who sees “2.0.0” knows to look for what’s gone before they open anything. The release tells people what changed, so nobody has to ask.
Five rules that keep it governed
The release pattern gives you control. These rules turn it into governance:
Every change is reviewed. In my business, a skill change gets reviewed before it can be released. A teammate, or an AI reviewer, reads it first.
Every skill change has revision history. Each change is saved in the skill source’s history, and each release names the version it came from. Any output traces back to the exact skill that produced it.
The plugin stays private. Only people you add can install it, and only a small group can release to it. Every release is somebody’s deliberate call.
Decide who gets each skill. Nothing ships until it’s assigned to a plugin or kept back. The release plan records who gets what.
Record what’s running. My AI Registry links every workflow to the skills and agents behind it, so I can see what’s released, which workflow it serves, and who owns it.
None of these rules are Claude-only. ChatGPT Business and Enterprise read the same skill format, so the skills and the rules carry over. Only the release mechanics differ by platform.
Leader Lens
The release step adds friction between “I improved the skill” and “the team has it.” That friction is the point. It’s what lets a leader say yes to the next skill instead of pausing to audit the last one. Decide who can release before you decide what to release, and the rollout keeps pace as the team grows.
Your next two weeks
Pick the one skill your team copies most. This week, find every copy and name a single owner. Next week, move it to one source and agree who can change it. You’ll know it worked when someone asks “which version is this?” and the answer takes seconds.
See it live this Friday
I’m teaching this as a free 45-minute Lightning Lesson on Maven on Friday, November 6, at 12:30 PM ET: How to Govern Claude Skills at Scale.
Using the setup I run my business on, I’ll add a skill, change one, and remove one. Each change gets released and arrives on a teammate’s setup with its version number. Then I’ll open the registry that records what’s running and who owns it. The last 15 minutes are for your questions, and the recording goes to everyone who registers.
If you want to build skills worth releasing on your own work, that’s what my course, Claude for Leaders: Accelerate Your Business, covers. Cohort 8 starts Monday, November 9.
If your team already shares skills differently, I’d like to hear how. Bring it to the Q&A, or reply to this email.
Stay curious. Stay hands-on.
James