Skills Are Versioned Org Assets
A skill is a folder with a markdown file in it. That is genuinely all it is, and it is why the first hundred skills in an organisation appear from nowhere: somebody writes one on a Tuesday afternoon, it works, they paste it into a colleague's repo, and now there are two copies with one owner between them.
Nobody notices the problem at ten skills. At a few hundred it is the same problem enterprise architecture has been dealing with for thirty years, and it has the same answer. A skill is a reusable asset. Reusable assets need a registry, an owner, a lifecycle, and a way to tell whether anyone is still using them.
The mistake is to reach for heavy governance first. What follows is the lighter version: guardrails where automation can carry them, human review only where a human genuinely has to look.
The operating model on one page, showing who owns what and where the single review gate sits: Skills as Versioned Org Assets →
A registry, not a folder full of copies
One central, git-backed marketplace of plugin bundles: skills, MCP servers and config together, in a single canonical repo. Not skills scattered per user, and not a wiki page listing where the good ones live.
Three tiers do most of the structural work. Personal is where drafts and experiments sit, cheap to create and easy to throw away. Team is shared within a domain. Org-wide is reviewed, versioned and governed hardest.
Discoverability then rests on two things: a naming convention, and description quality. That second one deserves more attention than it usually gets. Triggering depends on the description field, so the description is not documentation, it is the API. A skill nobody's agent ever pulls in is not a skill, it is a file.
Every skill has an owner and a status
Status flows draft, reviewed, published, deprecated. The last one matters more than it looks: there needs to be a deprecation path, because the alternative is silent deletion, and silent deletion is how you teach people not to depend on the registry.
Semantic versioning plus a changelog on every skill. And a graduation path, so a personal skill can be promoted to team or org tier after review. That path is the point of the tiers. Good ideas start as somebody's Tuesday afternoon experiment, and the structure should carry them upward rather than force them to be born official.
Guardrails over gates
Lightweight human review, but only before an org-wide publish, and only for the things a human is actually needed for: which MCPs and tools the skill touches, whether it handles secrets or network access, whether it is correct, whether there is PII sitting in a prompt.
Everything else is automated on every publish. Lint the SKILL.md, validate the schema, run a description-quality and trigger eval, scan for forbidden patterns. A skill with write or side-effect tools clears a higher bar than a read-only one, which is the same instinct that runs through the agent systems in this workspace: the tool grant is the guardrail, so the tool grant is what gets the scrutiny.
Review boards fail when they are asked to look at everything. Point one at the small set of changes that can actually hurt and it will keep working.
Distribution and pruning
Install through the marketplace, never by copying files. Consumers subscribe, updates propagate, and teams that cannot absorb surprises pin versions. Access control separates who may publish org-wide from who may consume, which is a different question from who may write.
Then measure, because a registry with no usage data becomes a graveyard nobody is allowed to clean. An eval harness per skill, benchmarking with variance analysis (already part of the skill-creator toolchain), and telemetry on invocation counts, trigger accuracy and failure rate. Prune what nothing invokes. Route thumbs-down and issue-tracker feedback to the named owner, which only works because there is a named owner.
The architecture angle
Here is the part that makes this feel familiar rather than new: a skill is a capability. Map the skill portfolio to the capability catalog and the duplication problem solves itself, because two skills claiming the same capability become visible the moment they are catalogued rather than three quarters later when someone notices.
It also helps to distinguish format skills (docx, pptx, the mechanical ones) from domain skills, the ones encoding how your organisation actually does something. Govern the domain ones harder. A shared authoring template keeps both consistent.
None of this is a new discipline. It is portfolio management applied to a new asset class, with the same ownership, lifecycle and catalog rules the practice already applies to applications and services. The novelty is only in how fast the asset class grew.
Before getting concrete
Three questions decide almost every detail above, and answering them first saves designing the wrong thing.
Scale. How many authors and consumers is this for? Tens gives a different answer than thousands, and most organisations quietly design for thousands while having tens.
Platform. Claude Code plugins only, or multi-tool including custom agents? The registry format follows from this.
Sensitivity. Do these skills touch production systems or customer data? That single answer sets the height of the governance bar, and it is the one worth asking before anything else.