Three ways to share a Skill: Git, plugin, enterprise

A PR review skill that only you use is helpful. The same skill, shared across your team, standardises code review and gives every engineer the same experience every time. That's the difference between a personal productivity hack and an organisational standard — and it's why distribution is worth thinking about carefully.

This lesson covers the three ways you can get skills into other people's hands, plus a gotcha that surprises almost everyone the first time they hit it: subagents don't inherit skills automatically.

Committing skills to your repository

The simplest distribution method is the one you already know how to do. Put skills in .claude/skills inside your repo root, commit them, push. Anyone who clones or pulls the repo gets those skills automatically — no install step, no separate configuration.

This is the right choice for:

• Team coding standards — linting conventions, review checklists, commit message formats
• Project-specific workflows — deployment procedures, release notes templates, test conventions
• Skills that reference your codebase structure — things that only make sense in the context of your repo

When you push an update to a skill, everyone gets it on the next pull. No distribution infrastructure required.

Distributing skills through plugins

Plugins are Claude Code's mechanism for extending functionality across teams and projects without tying it to a single repository. If your skills have value beyond one codebase — maybe a general-purpose accessibility auditor, or a standard API documentation formatter — a plugin is the right shape.

Inside your plugin project, create a skills/ directory that follows the same structure as .claude/skills: one directory per skill, each containing a SKILL.md. Once the plugin is published to a marketplace, other users can install it and pick up your skills as part of that plugin.

This is the best fit for cross-project, community-useful skills that aren't tied to any one codebase.

Enterprise deployment through managed settings

Administrators can deploy skills organisation-wide through managed settings, and these skills take the highest priority — they override personal, project, and plugin skills with the same name. This is the right mechanism for things that must be consistent across an organisation: mandatory coding standards, security requirements, compliance workflows.

Enterprise settings also support strictKnownMarketplaces for controlling which plugin sources teams are allowed to pull from:

"strictKnownMarketplaces": [
  {"source": "github", "repo": "acme-corp/approved-plugins"},
  {"source": "npm", "package": "@acme-corp/compliance-plugins"}
]

If your organisation already has a plugin allowlist, this is where it lives.

The subagent gotcha

Here's the part that surprises people. Subagents don't automatically see your skills. When you delegate a task to a subagent, it starts with a fresh, clean context — no skills, no conversation history, just the task you handed it.

There are two implications:

• Built-in agents (Explorer, Plan, Verify) can't access skills at all. There's no configuration hook for them.
• Custom subagents that you define can use skills, but only when you explicitly list them in the agent's frontmatter.

And here's the second wrinkle: when a custom subagent does use skills, those skills load when the subagent starts, not on demand the way they do in the main conversation. That changes the calculus of which skills to list.

Wiring skills into a custom subagent

Custom subagents live in .claude/agents/ as markdown files with their own frontmatter. The skills field is where you list which skills the agent should load:

---
name: frontend-security-accessibility-reviewer
description: "Use this agent when you need to review frontend code for accessibility..."
tools: Bash, Glob, Grep, Read, WebFetch, WebSearch, Skill
model: sonnet
color: blue
skills: accessibility-audit, performance-check
---

You can create subagents interactively with the /agents command in Claude Code, or edit the file directly if the agent already exists — just add a skills: line to the frontmatter listing the skills you want loaded.

When you delegate to this subagent, it starts with both accessibility-audit and performance-check already loaded, and applies them to every review. That's the point: isolated task delegation with specific, pre-loaded expertise.

Rules of thumb for subagent skills

Because skills load at subagent start rather than on demand, you want to be selective. Only list skills that are always relevant to the subagent's purpose. A frontend reviewer shouldn't load a backend security skill it won't use — that's just context you're burning before the work even starts.

A good pattern: one subagent per review discipline (frontend reviewer, backend reviewer, security reviewer), each loading only the skills that apply to its domain. Different subagents, different skills, each with a focused context.