Versioning, review, and audit
Once a skill is shared, a quiet thing has happened: a piece of text now writes work for your whole team. That is a different category of object from a personal note. It deserves the discipline you give code that runs in production — because, effectively, that is what it is.
Review before it lands
The first rule is the simplest and the most often skipped: a shared skill is reviewed before it enters the library, not after. Reviewing after means a flaw is already shaping work across the team before anyone looks at it.
Treat the skill the way you treat a pull request. Someone other than the author reads it. Does the description trigger it at the right times and only those? Are the instructions standing rules, not one-off steps? Does it carry its guardrails — the "never do this", the verify-before-mutate, the self-check? An unreviewed skill in a shared library is an unreviewed standard, and the cost of a flaw multiplies by everyone who uses it.
Version it like you mean it
In Track 2 the rule was "when you change a skill, you change every future output." At team scale that is not a caution — it is the whole reason versioning matters. Edit a document and you have changed a document. Change a shared skill and you have changed the shape of everything it will produce, for everyone, from now on. The blast radius is all subsequent work.
So version skills deliberately. Meaningful version numbers, a changelog that says what changed and why, and the discipline to treat a skill edit as amending a standard rather than tweaking a file. A production library carries its version explicitly and records changes — copy that. When someone asks "did the status-report skill change last week?", the answer should be in the history, not in someone's memory.
Ownership: someone answers for it
Every shared skill needs an owner — a person who answers for what it does and approves changes to it. This is not bureaucracy; it is the Grunden applied to a shared artifact. Personal responsibility does not evaporate because a skill is now used by ten people. It concentrates: the owner is accountable for the standard the skill encodes, the way an author is accountable for code they merge.
Without an owner, a shared skill drifts — patched by whoever, trusted by everyone, answerable to no one. With one, there is a person to review against, to ask, and to hold the line on quality.
Audit what it can reach
The review that matters most is not about prose — it is about reach. A skill that only produces text is relatively low-risk. A skill wired to your tools and data can change records, call services, read sensitive information. That is where audit belongs: what can this skill access, and what can it do?
Borrow the production patterns directly. A skill with reach should carry its explicit "never do this" contract and its verify-before-mutate checks, and those become governance primitives — the things a reviewer confirms are present before the skill is allowed near real systems. Skills with the ability to change things are privileged automation, and they get the scrutiny privileged automation gets.
What comes next
Review, versioning, ownership, and audit govern a skill library within a team. The final part scales that up: org-level libraries, access control, enforced standards, and the point at which a skill stops being a convenience and becomes policy the organisation is accountable for.
Next in this series: Part 3 — Org-level skill libraries and governance