Org-level skill libraries and governance

There is a line a skill crosses, often without anyone noticing. On one side it is a convenience — a faster way for a person to do their work. On the other it encodes a process the organisation is accountable for. Once a skill is on the far side of that line, how it behaves is no longer a matter of preference. It is policy. This final part is about governing skills once they matter that much.

From individual AI to organisational AI

The earlier tracks were about individuals and teams getting good at skills. Organisational AI is a different claim: that the organisation, not just its people, owns how AI is used. A scattering of personal skills, however good, is not that. It is a collection of habits with uneven quality and invisible risk.

The shift to organisational AI happens when skills become a governed, shared standard — when the question "how do we do this with AI?" has an answer that lives in a reviewed library, not in individual memory. Everything in this series has been building toward that: single-purpose skills, defensive design, distribution, review, ownership. Governance is what holds them as an organisational standard rather than a pile of good intentions.

When a skill becomes policy

The test is accountability, not headcount. A skill that drafts your internal status notes is a convenience even if a hundred people use it. A skill that encodes a compliance step, a customer-facing process, or a financial workflow is policy the moment it exists, even if three people use it — because the organisation answers for what it produces.

Identify those skills explicitly. They are the ones that need the full weight of governance: enforced standards, named ownership, audit of what they touch, and review that treats a change as a change to a process the organisation is liable for. Do not govern everything to the same degree — govern by accountability, and spend the scrutiny where the risk actually is.

Enforcing a standard

For skills that are policy, "please use the approved version" is not enough. The mechanisms that make a standard real:

Enterprise-managed settings deploy skills as enforced, read-only configuration across the organisation. Combined with scope precedence — managed settings sit above user and project levels — this is what guarantees the approved skill is the one that actually runs, regardless of what an individual has locally. It is the difference between a recommended standard and an enforced one.

Marketplaces with allow and deny lists govern what can be installed at all, with version pinning so teams run a known-good version rather than whatever is latest. This controls the supply of skills, not just their content.

Access control is the other half: who can install a skill, who can invoke a privileged one, who can change a governed one. The owner from Part 2 sits inside this — a governed skill has not just an author but an access boundary.

The gap nobody mentions: skills do not sync across surfaces

Here is the governance reality that catches organisations out. Skills in Claude Code (filesystem), the API (workspace), and the Claude apps (user-scoped) are separate stores. Enforcing or uploading a skill in one does not propagate to the others. On some surfaces, custom skills are not centrally managed at all.

The implication is direct: a standard you enforce for your engineers in Claude Code does not automatically govern a colleague using the consumer app, and "we enforced it" can be true for one surface and false for the rest. A governance framework has to account for which surfaces your people actually use, and treat each as its own perimeter. The danger is not the gap itself — it is the false confidence of thinking one enforcement covers everyone.

A framework an organisation can live with

Pulling the series together, a workable skills governance framework has five parts:

1. Classify by accountability — separate convenience skills from policy skills; govern the latter heavily, the former lightly.
2. One reviewed source — a shared, version-controlled library; review before merge; named owners.
3. Enforce where it matters — managed settings and precedence for policy skills; marketplaces with allow lists to control supply.
4. Audit reach — know what privileged skills can access and do; require their guardrails.
5. Cover every surface — map where people use Claude and govern each perimeter; do not assume one enforcement reaches all.

That is governance an organisation can actually live with: heavy where the risk is, light everywhere else, and honest about the gaps. It is the same principle that runs under everything Mindtastic teaches — you own what you ship — scaled from one person's commit to an organisation's standard.

Where this leaves you

That completes the skills curriculum: from "what a skill is" for an individual, through composing and producing them, to governing them as an organisational standard. The thread through all of it is the one idea worth keeping: a skill is owned judgment, made reusable. Capture it well, validate it honestly, and govern it deliberately, and a single person's good thinking becomes capability the whole organisation can rely on.

This completes Skills as Governance, and the skills curriculum. Return to Skills Fundamentals for the foundations, or Skills in Production for the developer track.