A teammate asks in Slack for "that release-notes skill you keep mentioning." You paste a folder. Two weeks later they are still on last month's version, and you have no idea. Sharing Claude Code skills is not the same problem as syncing your own laptop and desktop — the consumers are other people, with other machines, and often other expectations about updates.
This guide covers how to share Claude Code skills with your team: project skills in git, internal plugin marketplaces, what breaks when you zip a folder once, and where a shared install surface helps.
Prefer project skills for anything the repo needs
If the skill encodes how this codebase works — test commands, PR conventions, deploy checklist — put it in the repository:
.claude/skills/<skill-name>/SKILL.md
Everyone who clones gets it. Reviews happen in pull requests. When you change the skill, the next pull updates the team. This is the default answer in Anthropic's skills docs and in most r/ClaudeCode threads about sharing.
Personal taste (your writing voice, your private checklist) stays in ~/.claude/skills/ and should not be forced onto teammates through the repo.
When project skills are not enough
Org-wide habits do not belong in every repository: a security review skill, a company style guide, a billing-runbook skill used across services. Copying the same folder into twelve repos guarantees drift.
Common patterns teams use:
- Internal plugin / marketplace repo. Point everyone's Claude Code marketplace at a private GitHub repo that packages skills as plugins. Install once with
/plugin install ...@your-marketplace. Updates flow when people update the plugin. - Shared skills library repo. One private repo of skill folders; each engineer clones and symlinks (or runs an install script) into
~/.claude/skills/. Simple, but update discipline is manual unless you automate pulls. - "Paste the zip" in Slack. Fast once, wrong forever. No version, no owner, no update path.
A Reddit thread on r/ClaudeCode asking how to share skills, plugins, commands, hooks, and MCP across a team landed on the same split: project-level in .claude, org-level as an internal marketplace or library — not repeated Slack attachments.
Package for install, not for curiosity
A shareable skill needs more than a clever SKILL.md body:
- A clear
descriptionso Claude (and humans) know when it fires - No machine-specific paths or personal API keys in the markdown or scripts
- A name that will not collide with a teammate's personal skill folder
- A documented trigger (slash command name = folder name)
If the skill depends on an MCP server, say so in the skill body and ship the MCP definition through .mcp.json or your team's MCP sync process — a skill that calls a missing tool fails silently from the user's point of view.
Keep MCP and skills in the same sharing story
Teams that share skills often need the same MCP servers. Commit project MCP to .mcp.json. For org-wide servers, document the claude mcp add line (without secrets) or distribute via the same internal marketplace / sync tooling you use for skills. Mixing "skills in git, MCP only on Alex's laptop" recreates the original Slack problem under a different name. See sync MCP servers across machines.
Where loadout fits for a small team
If your "team" is three engineers each on two machines, git project skills plus a private marketplace may be enough. Friction shows up when:
- people forget to update the plugin
- personal and shared skills get mixed in one folder
- you also want a browsable catalog instead of a repo README
loadout is built around a marketplace and a background agent that applies installs onto paired machines. You can publish skills for others to install, and each person's fleet stays current without a weekly "did you pull?" nudge. It is free to start; use it alongside — not instead of — project-scoped .claude/skills/ for repo-specific behavior.
If a skill is part of how the team ships, it belongs in version control or a marketplace with an update path — not in someone's Downloads folder.
Rollout checklist
- Sort skills into project vs org vs personal.
- Move project skills into each relevant repo; open a PR so the team sees them.
- Stand up an internal marketplace or shared library for org skills.
- Document MCP dependencies next to the skill, with secrets out of band.
- Pick an update ritual: plugin update command, scheduled pull, or agent-applied installs.
- Onboard the next hire with a written "install these three things" doc — if that doc is longer than a screen, the sharing model is too manual.
FAQ
Can I commit my whole ~/.claude/skills into a company repo?
You can, but you will leak personal experiments and maybe secrets. Publish curated skills as project skills or marketplace plugins instead.
Do teammates need the same Claude Code version?
Stay reasonably current. Skills are markdown-first, but frontmatter fields and plugin APIs change; pin a minimum version in your team doc if you rely on newer features.
How do we revoke a shared skill?
Remove it from the marketplace or repo and tell people to update/remove the install. There is no global kill switch across unmanaged home directories — another reason a managed install path beats zip files.
Is sharing skills the same as sharing CLAUDE.md?
Related but different. CLAUDE.md is always-on context; a skill is loaded when its description matches or when someone runs the slash command. Many teams share both: project CLAUDE.md for baseline rules, skills for repeatable workflows.