How to share Claude Code skills with your team

You wrote a skill that makes Claude Code review pull requests exactly the way your team wants. It works. Now five colleagues want it — and in six months, fifty might. How do you get it onto their machines, keep it updated, and stay in control of who has what?

Teams converge on one of four answers. Here is what each one actually costs.

Option 1: paste it in Slack

The zero-infrastructure answer: zip the folder, drop it in the team channel, everyone extracts it into ~/.claude/skills.

It works exactly once. The problems start with the first update: there is no way to know who extracted which version, no way to push a fix, and the "current" version lives in someone's chat scrollback. Six months later the team runs four silently different variants of the same skill and debugging why "the agent behaves differently on my machine" becomes a recurring meeting.

Option 2: a skills folder in the repo

Commit skills to the project repository — .claude/skills/ or the shared .agents/skills/ convention — and let everyone get them with git pull.

This is genuinely fine for project-scoped skills: conventions that only matter inside that codebase. It breaks for everything else:

• Company-wide skills (release process, security review) would need to be copied into every repo — and copies drift.
• Contractors and teammates get skills only for repos they can clone; access control equals repo access, which is rarely the boundary you want.
• Skills for people who don't touch that repo — support engineers, data folks — have nowhere to live.

Option 3: a dedicated skills repo

One git repository holding all the team's skills, plus a script that symlinks them into each agent's folder.

Closer — now there is a single source of truth and a history. What's still missing is everything around the files: no versioning beyond commit hashes ("which commit is safe to run?"), no per-skill access (the repo is all-or-nothing), no way to see who has installed what, and a hand-rolled linking script that breaks on the one OS you didn't test. You will also write per-agent logic yourself the day someone on the team prefers Cursor or Codex over Claude Code.

Option 4: a private registry

The same move the software industry made for libraries: a registry where skills are published with a version, an owner, and access rules — and installed with one command.

masterskills add @acme/secure-code-review

What a registry buys you over a git repo, concretely:

• Versions with intent. Publish v2, let teams pin v1, roll back when v2 misfires. Commit hashes can't express "this one is approved".
• Access as policy, not repo membership. The security team's skills stay with the security team, client-specific skills stay inside the client workspace.
• Every agent, one install. The registry's CLI links a skill into every coding agent detected on the machine — Claude Code, Codex, Cursor, Gemini CLI, and 70+ others — instead of one folder per tool.
• An answer to "who runs what?" Install state is visible, which turns "did everyone get the fix?" from a poll in Slack into a glance at a dashboard.

This is what MasterSkills does, with one more property the git options can't offer: the agent itself operates the registry. A teammate says "install the review skills" in plain language, and the agent — bound by explicit approval rules — does the rest. Nobody learns a new tool; the tool learned them.

Which one should you pick?

Honest answer: match the tool to the blast radius. A solo developer needs a folder. A single team working in one repo does fine with committed skills. The moment skills cross team or repo boundaries — or the moment you ask "which version is Maria running?" and nobody knows — you have outgrown files, and you need a registry.