Skill Governance for Enterprise AI: The Vacation Problem

At a governance conversation with one of our enterprise clients a couple of weeks ago, the AI program lead asked a question we keep coming back to. It was not about which model is safest, or how to log usage. She asked a sharper one: what happens when the person who built the team's best skill goes on vacation?

That is the whole problem in one sentence. Someone on the team writes a skill that turns a two-hour task into a two-minute one. Everyone wants it. And it lives in exactly one place: that person's session, on that person's machine. When they log off, so does the skill.

We have written before about governing the MCP servers an organisation connects to and about what AI governance actually means. Skills are the next artifact that needs the same treatment. They are becoming the unit of reuse in agentic AI, the packaged bit of know-how a team hands around. And in most organisations right now, nobody governs them at all.

A skill feels like a file, so people assume sharing it is like sharing a file. It isn't, and the reasons are specific to how the desktop AI tools are built today.

Claude gives you three ways to distribute a skill, and they sit on very different rungs of the governance ladder.

Export a zip and send it. You download the skill, send it to a colleague, they upload it. It works for a one-off. There is no version history, no review, no naming discipline, and no way to build governance on top of it. Fine for "here, try this," useless as an organisational practice.

Publish it to the whole organisation. If an admin enables it, an owner can push a skill to everyone in the org with one button. Everyone sees it in the catalog and can install it. For a smaller organisation this is genuinely good. Two caveats. First, naming hygiene stops being optional the moment more than a handful of skills exist. Second, on a Team plan everyone sees everything; visibility scoped to groups (so the Legal team's skills don't clutter Engineering's catalog) is an Enterprise feature. On Team, you replace group-level visibility with a naming convention.

Back it with a Git repository. An admin points the organisation's plugin marketplace at a private or internal repo, and the marketplace re-syncs on every merged pull request. This is the option that carries governance, because Git already is a governance system: history, review, ownership, CI. It is also the one with the sharpest edges, which we will get to.

Here is the detail that reframes the whole thing, and it is easy to miss.

A skill created during a Cowork session does not reach any further than that session. It lives in that one session's workspace, on that one person's account, and nothing guarantees it outlives the session. Nobody else can get to it — not from another session, not from another surface. More broadly: across the desktop surfaces (Chat, Cowork, the Code terminal, Code in VS Code) there is no shared skill store. Each surface is its own silo. Claude Code does not automatically see a skill someone created in Cowork.

Matyáš Křeček, who leads our MCP Gateway work and has been designing exactly this setup for a client, put the implication plainly:

This flips the usual objection. Teams sometimes push back on a repo-first approach as heavyweight, asking why people cannot just share skills directly. The honest answer is that there is no reliable direct path. Without a repo, a skill built in Cowork exists in exactly one place that nobody else can see into. The repository is not extra process bolted on top of sharing. It is what makes the skill exist beyond a single session.

The moment you say the words Git repository, most of the organisation checks out. Legal, ops, and finance — the people who often build the most valuable domain skills — are not going to write commit messages. So the design goal is simple. Keep the repo as the source of truth, and make sure nobody outside engineering ever has to know it is there.

That is doable today, and it does not require non-technical people to touch Claude Code at all.

The mechanism is a /sync-skill command, shipped inside a core plugin that the admin marks as auto-installed so everyone has it from day one. Cowork can run commands in its VM and has a GitHub connector. So when someone in Legal finishes a skill and types /sync-skill, the command can take the current skill folder, create a branch, commit the files, and open a pull request through the GitHub connector. The person answers a couple of prompts — name, description, which team — and never thinks about Git.

Discovery falls out of the same structure. Plugin skills are namespaced as /plugin-name:skill, so a legal plugin gives you /legal:contract-review, and anyone can find their team's skills by typing /legal. The naming convention you needed anyway for the Team-plan visibility limit is the same one that makes skills discoverable.

A repo-backed marketplace is the right architecture, but two of its edges will hurt if you ignore them. Both belong in the governance rules from day one.

Validate in CI before merge, always. The marketplace re-syncs on merge, and when a sync fails, plugins can temporarily disappear for the whole team. That turns a bad merge into an outage. So CI validation — linting the marketplace manifest, checking required frontmatter fields, enforcing the naming convention — is not a nice-to-have you add later. It is the thing that stops one malformed skill from taking down everyone's toolbox.

Treat bundled MCP servers as privileged code. A plugin can contain local MCP servers, and those run on the user's machine with the same rights as any other program. On an Enterprise plan an admin can disable local MCP servers centrally; on a Team plan you cannot enforce that from the centre. The pragmatic rule that follows: skills contributed by non-technical people are SKILL.md plus reference files only — no MCP servers, no hooks. Anything that ships executable surface goes through technical review. This is the same instinct behind treating context as an architecture problem rather than a prompting one: the risk is in what the artifact can do, not in what it says.

You do not need the full setup to start. The ladder is roughly:

The same repository serves Claude Code too, by the way. The admin marketplace reaches Cowork and Chat automatically but not Code; developers add the same repo manually with a one-line marketplace command. One source of truth, three surfaces, different distribution channels.

Come back to the question that started this. What happens when the author of your best skill goes on vacation? With no governance, the honest answer is: the skill goes with them, and you find out the hard way.

With a repo-backed marketplace, a /sync-skill path for non-technical contributors, and CI that refuses to break the team's toolbox, the honest answer is almost boring. Nothing breaks when the author is away. The skill is in the repo, it has an owner in CODEOWNERS, and it passed review. Everyone can already use it by typing its name.

That is what skill governance buys you. It is the same discipline we bring to the MCP servers an enterprise connects to, pointed at a different artifact. If you are working through where the control plane for AI tooling should sit in your organisation, that is the conversation behind our MCP Gateway Enterprise work — and skills are now part of it.

A skill that only lives in one person's session is not an asset. It is a liability waiting for a vacation.