Git-distributed skills: inheritance and the team
A skill on one person's machine is a personal habit. The moment a team relies on skills, the question changes from "is this a good skill?" to "whose skill, which version, and who can change it?" That is governance, and it starts with how skills are distributed.
The gap you are closing
Picture a team a few months into using AI seriously. One engineer uses skills carefully, with guardrails. Another vibe-codes a feature with a skill they wrote in five minutes. A third has wired up a workflow nobody else knows exists. Individually, each might be fine. Collectively, the organisation has no idea what its standard is — and it will not find out until something uneven reaches production.
That is the individual adoption gap, and it is precisely a governance problem. The answer is not more enthusiasm or more training alone. It is making skills shared, version-controlled, and reviewable — turning private habits into a team standard you can actually see.
Distribution: commit it to the repo
The simplest mechanism is the most familiar: a skill committed to a project's skills directory travels with the repository, under version control, available to everyone who works in it. It is shared and versioned by exactly the same mechanism as your code — pull the repo, get the skills. This is how a production library does it: clone, bootstrap, and the team's skills are present.
Beyond per-project git, two mechanisms extend the reach. Plugins and marketplaces let you package skills (along with related tooling) and distribute them through a registry, with version pinning and allow or deny lists — useful when many teams should share a set. Enterprise-managed settings push skills organisation-wide as enforced, read-only configuration. Which you reach for depends on scale; the principle is constant — one reviewed source, distributed, not copied.
Inheritance: do not let every skill repeat itself
A team library that copies the same standards into every skill is a maintenance trap waiting to spring. The pattern that scales is inheritance, and it has two parts.
A base skill holds the shared standards and vocabulary — the priorities, the statuses, the conventions every domain skill should follow. Domain skills inherit it and add only what is unique to them. The base is background knowledge, not a command you invoke; it informs the others quietly.
Layered configuration handles the values that differ by environment: a project layer overrides an organisation layer, which falls back to base defaults — first match wins. Organisation-specific configuration lives in its own place, extending the generic core rather than forking it. And the local facts particular to one setup stay in CLAUDE.md as the single source of truth, while the skills carry generic procedure.
The result: a shared standard changes in one place, and every skill stays focused on what makes it distinct. That is what makes a library survive a growing team.
Scope precedence: which skill actually wins
When the same skill can exist at several levels, you need to know which applies. The order, highest to lowest: enterprise-managed settings, then user-level, then project-level, then plugin-provided. Higher scope overrides lower.
This is not a footnote — it is the lever of governance. It is how an organisation guarantees that its reviewed, standard version of a skill is the one that runs, regardless of what an individual happens to have locally. Without knowing the precedence, "we have a standard skill" is a hope. With it, it is enforceable.
What comes next
Distribution makes a skill shared. It does not make it trustworthy. The next part covers treating skills like code: review before a skill enters the library, versioning, and clear ownership of what each one does.
Next in this series: Part 2 — Versioning, review, and audit