How to Share AI Agent Skills with Your Team (2026)

You wrote a Claude Code skill that saves you twenty minutes a day. Your teammate is doing the same task by hand. The gap between those two facts is a distribution problem, and most teams solve it badly: someone pastes a folder in Slack, three people install it, two of them have a slightly different version a month later, and nobody knows which one is current.

Sharing skills well isn't hard, but it does need a system. Here's how to get a skill from your machine to your whole team so everyone runs the same version, updates land cleanly, and nobody installs something they haven't read.

What a skill is

A Claude Code skill is a folder with a SKILL.md file at its root, plus any scripts or reference files it needs. That's the whole format. Because it's just files, sharing a skill is just sharing a folder, which means every tool your team already uses for sharing folders works: git, a shared drive, a package registry.

The SKILL.md has YAML frontmatter with a name and description, then the instructions in the body. The description is what tells Claude when to reach for the skill, so a vague description is the most common reason a shared skill sits unused: Claude never triggers it. Before you share anything, make sure the description names concrete triggers.

The three ways to share, ranked

Skip the third one for anything you'll use more than once. It feels fast and creates version drift within a week.

Method 1: A plugin marketplace (the right default for teams)

Claude Code supports plugin marketplaces, a git repository that lists one or more plugins, each of which can bundle skills, commands, and MCP servers. This is the cleanest way to distribute skills across a team because installs and updates go through one command, and everyone points at the same source of truth.

The rough shape:

# A teammate adds your team's marketplace once
/plugin marketplace add your-org/your-skills-repo

# Then installs the plugin that carries your skills
/plugin install team-skills

When you push an update to the repo, teammates refresh from the marketplace and get the new version. No copy-paste, no "which version do you have." The repo becomes the canonical home, and your SKILL.md files live inside it under the plugin's structure.

The upfront cost is setting up the marketplace repo layout once. After that, adding a skill is a commit, and rolling it out is a message saying "run the update." For a team past three or four people, this pays for itself quickly.

Method 2: A plain git repo

If a full marketplace feels like too much, a shared git repository is the honest minimum. Put your skills in a repo, and have teammates clone or symlink them into their skills directory:

# Clone the team skills repo
git clone https://github.com/your-org/claude-skills.git

# Link a skill into your personal skills directory
ln -s "$(pwd)/claude-skills/pdf-cleanup" ~/.claude/skills/pdf-cleanup

The symlink trick matters: it means a git pull updates the skill in place, so nobody re-copies anything. The tradeoff versus a marketplace is that installs are manual and there's no built-in version display, but for a tight team that reviews each other's commits, it's plenty.

Method 3: Personal vs project skills

One decision people miss: where the skill should live. A skill in ~/.claude/skills/ is personal: it follows you across every project. A skill committed into a project's .claude/skills/ folder ships with the repo, so anyone who clones that project gets it automatically, no separate install.

For a skill that only makes sense inside one codebase (say, a deploy routine specific to that app), put it in the project. It travels with the code and stays scoped to where it's useful. For a general skill like a writing scrubber or a PDF tool, keep it personal or push it through the marketplace so it's available everywhere.

The security step nobody wants to do

A skill can run scripts. That means installing a teammate's skill is running their code, and installing a skill you found online is running a stranger's code. Before any skill goes team-wide, someone who isn't the author should read it.

What to check:

• Read the SKILL.md and every script it references. If it fetches from a URL, runs a shell command, or touches files outside the project, know why.
• Watch for install commands that pipe to a shell: curl ... | bash in a skill is the same risk it is anywhere else.
• Confirm the source. A skill from your own repo is one thing. A skill copied from a public list needs the same scrutiny you'd give any dependency.

This isn't paranoia. A skill with a plausible description and a quietly malicious script is a real supply-chain vector, and "it came from a teammate" isn't a review. Make the read a required step before anything lands in the shared repo. Our guide on how to audit agent skill security covers the audit process in more depth.

A workflow that holds up

Here's the setup I'd recommend for a team that's serious about it:

1. One git repo, structured as a plugin marketplace, owned by the team. 2. Every skill goes in through a pull request, so at least one other person reads it before it merges — that's your security review and your quality check in one step. 3. Teammates install from the marketplace and refresh on a known cadence, so versions stay aligned. 4. Skills that belong to a single project live in that project's .claude/skills/, not the shared repo.

The tools (skill-creator for building, a marketplace repo for distributing) matter less than the habit: one source of truth, a human reads every skill before it spreads, and updates go out the same way every time. Get that right and a skill one person wrote on a Tuesday is running on ten machines by Friday, all the same version.

FAQ

Where do Claude Code skills get installed? Personal skills live in ~/.claude/skills/, each in its own folder with a SKILL.md. Project-scoped skills live in the project's .claude/skills/ and ship with the repo when someone clones it.

What's the difference between a skill and a plugin? A skill is a single folder with instructions Claude follows for a task. A plugin is a bundle that can contain multiple skills, slash commands, and MCP servers, distributed through a marketplace. If you're sharing several related skills, a plugin is the tidier package.

How do teammates get updates to a shared skill? With a marketplace, they refresh from it and get the new version. With a plain git repo and symlinks, a git pull updates the skill in place. The zip-in-Slack method has no update path, which is why it goes stale.

Is it safe to install a skill someone shared with me? Only after reading it. A skill can run scripts, so installing one runs that code on your machine. Read the SKILL.md and any scripts, check for anything that fetches from URLs or runs shell commands, and confirm you trust the source before installing.

Can I share a skill that's specific to one project? Yes, and you should put it in that project's .claude/skills/ folder rather than the shared team repo. It ships with the code, stays scoped to where it's relevant, and everyone who clones the project gets it without a separate install.