How to Share Claude Skills With Your Team

Claude Code skills are easy to write and easy to hoard. Every developer ends up with a private collection in ~/.claude/skills/ — a code-review skill here, a release-checklist skill there — and none of it reaches the rest of the team. There are three practical ways to share Claude skills with your team: commit project-scoped skills to a git repo, distribute them as plugins through a team marketplace, or publish them to a hosted registry with access control.

Which one you pick depends on how many repos you have, how many tools your team uses, and how much governance you need. A five-person team working in one repo can get away with git. A fifty-person org with private skills, mixed editors, and compliance requirements needs more. This guide walks through all three options with real commands, then covers versioning, rollout, and how to figure out which skills your team actually uses.

The problem with everyone maintaining their own skills

Skills are instructions, and instructions drift. When each developer maintains their own set, you get:

• Duplicated effort. Three people independently write a "write migrations the way we do" skill. All three are slightly different, and only one of them is right.
• Silent divergence. Someone fixes a flaw in their copy of a skill. Nobody else gets the fix.
• Onboarding pain. A new hire's Claude Code knows nothing about your conventions until they manually collect skills from teammates' dotfiles.
• No review. Skills change agent behavior. Unreviewed skills mean unreviewed behavior — nobody signed off on what the agent was told to do.
• Tool fragmentation. Half the team uses Claude Code, the other half uses Cursor or Windsurf. A skill that only lives in .claude/skills/ helps exactly half the team.

Claude skills for teams need the same infrastructure you already expect for code: a single source of truth, versioning, review, and a distribution mechanism. The three options below provide increasing amounts of each.

Three ways to share Claude skills with your team

Option 1: a git repo and project-scoped skills

Claude Code loads skills from two places: your personal ~/.claude/skills/ directory and the project-scoped .claude/skills/ directory inside a repo. Project-scoped skills travel with the code, so committing them is the fastest way to share.

Step 1 — move the skill into the repo:

your-repo/
├── .claude/
│   └── skills/
│       ├── code-review/
│       │   └── SKILL.md
│       └── release-checklist/
│           ├── SKILL.md
│           └── scripts/
│               └── check-versions.sh
├── src/
└── package.json

Step 2 — commit and push:

git add .claude/skills/
git commit -m "chore: add shared code-review and release skills"
git push

Step 3 — teammates pull. That's the whole distribution story: the next git pull delivers the skills, and Claude Code picks them up automatically in that project.

This works well for a single repo. It breaks down quickly beyond that:

• Per-repo duplication. Ten repos means ten copies of the same skill, each drifting independently. Fixing a skill means ten PRs.
• No cross-repo private sharing. Skills that apply everywhere (security review, PR conventions) don't have a natural home.
• Claude Code only. Cursor and Windsurf users on the same team get nothing from .claude/skills/.
• No usage signal. You can't tell whether anyone's agent ever triggered the skill.

If your team lives in one repo and one tool, stop here — git is enough. Otherwise, keep reading.

Option 2: plugins and a team marketplace

Claude Code plugins bundle skills (along with commands, agents, and hooks) into an installable unit, and a marketplace is just a git repo with a .claude-plugin/marketplace.json manifest that lists your plugins. That makes a private team marketplace a natural next step: one repo holds the canonical skills, and every other project installs from it.

Step 1 — create a marketplace repo with your plugins and a manifest:

{
  "name": "acme-plugins",
  "owner": { "name": "Acme Engineering" },
  "plugins": [
    {
      "name": "acme-standards",
      "source": "./plugins/acme-standards",
      "description": "Code review, migrations, and release skills"
    }
  ]
}

Each plugin folder carries its skills in a skills/ directory, so one plugin can ship your whole starter set.

Step 2 — teammates add the marketplace and install:

/plugin marketplace add acme/claude-plugins
/plugin install acme-standards@acme-plugins

Now there's one canonical copy, updates flow from a single repo, and skills work across every project without being committed to each one. We cover the full setup — manifest layout, private repo auth, update flow — in our guide to building a private Claude plugin marketplace.

The remaining gaps are structural:

• Still Claude Code only. The plugin format doesn't help your Cursor or Windsurf teammates.
• Access control is repo-shaped. You can't give the platform team edit rights on infra skills while everyone else is read-only, beyond what git hosting offers on the whole repo.
• Manual adoption. Everyone has to add the marketplace themselves, and there's no way to see who did.

Option 3: a hosted registry with access control

The third option is to treat skills like packages: publish them once to a registry, install them anywhere, and manage who can see and edit what. This is what localskills.sh is built for, and it's the right shape once you need a private skill registry that spans repos, tools, and teams.

Step 1 — install the CLI and sign in:

npm install -g @localskills/cli
localskills login

Step 2 — publish your first shared skill. Every skill is a package with a root SKILL.md; multi-file skills with docs, scripts, and templates work too, up to 100 MB and 500 files per version:

cd skills/code-review
localskills publish

Step 3 — organize your team skill library. Organizations get folders and namespaces, so you can structure skills by area — acme/backend/, acme/frontend/, acme/security/ — with folder-level access restrictions where a subset of skills should only be visible to certain teams. Member roles (and custom roles) control who can publish, edit, and delete.

Step 4 — everyone installs, whatever tool they use. One published skill installs into every tool's native format — .claude/skills/ for Claude Code, .cursor/rules (.mdc) for Cursor, .windsurf/rules/ for Windsurf:

localskills install acme/code-review --target claude cursor windsurf

Step 5 — provision skills across your organization. Instead of inviting people one by one, larger orgs can wire up SAML SSO (with setup templates for Okta, Cloudflare Access, and Authentik), SCIM directory sync, and verified-domain auto-join, so new engineers land in the org — and in reach of the skill library — on day one. Audit logs record what changed and who changed it.

Agents can also reach the registry directly: localskills ships an MCP server, so Claude Code can search and install skills over MCP with OAuth and scoped access, without anyone leaving the terminal.

The trade-off versus git is that it's another account and another system. The payoff is that sharing stops being a per-repo, per-tool, per-person chore. For the broader playbook on getting a whole team onto shared conventions, see our guide to standardizing AI coding across your team.

Versioning, updates, and rollout

However you share Claude skills with your team, treat skill changes like code changes — they alter what your agents do.

1. Version every change. In git, that's commit history. On localskills.sh, every publish creates a new version with rollback, so a skill edit that makes the agent worse is a one-step revert rather than an archaeology project.
2. Keep a review path. With a registry, GitHub sync mirrors your org's skill library to a repo bidirectionally — edits made in the repo import back as new skill versions. That means skill changes can go through the same PR review as everything else, while installs still come from the registry.
3. Roll out deliberately. Start with three to five high-value skills (code review, migrations, release process) rather than dumping thirty on the team at once. A small library that's obviously useful builds the habit; a huge one gets ignored.
4. Name owners. Someone should own each skill the way someone owns each service. Roles make this explicit: give the owning team edit rights, everyone else install rights.
5. Announce updates. When a widely-installed skill changes behavior, say so in the same channel you'd announce a lint rule change. Then teammates re-run the install command to pick up the new version.

Measuring which skills your team actually uses

A shared library only matters if it's used, and "everyone installed it" is not the same as "it's shaping the code." Download analytics are built into localskills.sh, so you can see which skills are being installed and which have flatlined.

That signal drives three decisions:

• Prune. A skill nobody has installed in months is either unknown or unhelpful. Fix the description, fold it into another skill, or delete it.
• Promote. If one team's skill is quietly getting installed across the whole org, make it official: move it into a shared folder and give it an owner.
• Iterate. Adoption dips after a rewrite tell you the new version is worse. Roll back and try again.

We go deeper on the feedback loop — what to track and how to act on it — in measuring skill adoption with analytics.

FAQ: how to share Claude skills with your team

Where do Claude Code skills live on disk?

Personal skills live in ~/.claude/skills/, and project-scoped skills live in .claude/skills/ inside a repo — each skill is a folder with a SKILL.md at its root. Committing the project directory shares those skills with everyone who clones the repo; a registry install writes into these same locations, so Claude Code treats shared skills exactly like local ones.

Can Cursor and Windsurf users share the same skills as Claude Code users?

Yes, if you distribute through a registry rather than a tool-specific folder. A skill published to localskills.sh installs into each tool's native format from the same source — .claude/skills/ for Claude Code, .cursor/rules for Cursor, .windsurf/rules/ for Windsurf — with one command: localskills install acme/code-review --target claude cursor windsurf.

How do new hires get the team skill library automatically?

With git or a plugin marketplace, onboarding is a documented manual step. With an organization on a registry, SCIM directory sync and verified-domain auto-join put new engineers into the org automatically, and from there one localskills install command (or an MCP-connected agent) pulls down the standard set.

Should team skills be public or private?

Skills that encode internal architecture, security practices, or anything proprietary should be private — visible only to your org, with folder-level restrictions for anything more sensitive. Skills are private, public, or unlisted per skill on localskills.sh, so a team can keep its internal library locked down while still publishing a few generic skills publicly.

---

Ready to give your team one shared skill library instead of a dozen private ones? Sign up for localskills.sh and publish your first team skill in a few minutes.

npm install -g @localskills/cli
localskills login
localskills publish