AI Skill Governance Glossary

AI skills are becoming part of how teams actually work. They package instructions, examples, scripts, reference material, and other context so an AI system can perform a repeatable task more consistently. Once several people rely on the same skill, ordinary management questions appear quickly: Who owns it? Which version should people use? Where did it come from? Who reviewed it? Has the approved update reached everyone using it?

The vocabulary around those questions is still inconsistent across AI providers. This glossary defines the terms Commonset uses when discussing reusable AI skills and the broader capabilities they represent.

AI skill

An AI skill is a reusable package of instructions and supporting material that helps an AI system perform a particular kind of work.

Depending on the platform, a skill can include instructions, reference documents, scripts, templates, examples, configuration, or other files. The exact format varies by provider.

A useful distinction is that the skill is the implementation. The business function it performs can outlive the particular provider or format.

For a deeper explanation, see Understanding Capabilities, Skills, and Commonsets.

AI capability

An AI capability is the durable function an organization wants an AI system to perform, independent of the specific provider or implementation.

For example, a company might have a capability called Security Questionnaire Review. Today it may be implemented as a Claude Skill. Later the same function might be represented in ChatGPT, an internal agent, or a repository-backed workflow.

Thinking in terms of capabilities makes it possible to preserve ownership, review history, provenance, and version decisions even when the underlying implementation changes.

AI skill governance

AI skill governance is the process of deciding how reusable AI skills are created, reviewed, approved, distributed, updated, and retired.

Governance is not the same as security scanning. A scanner may identify suspicious or risky behavior. Governance also covers questions such as who owns a skill, what version was reviewed, which teams may use it, whether a change requires another review, and how an approved version reaches the people who depend on it.

The goal is not to review every experiment. It is to make shared, consequential AI work manageable once other people begin relying on it.

AI skill registry

An AI skill registry is a system of record for reusable AI skills and related capabilities.

A registry can record what exists, who owns it, where it came from, which versions exist, which version is approved, what providers or repositories it is connected to, and where it has been distributed.

A registry is most useful when it answers operational questions rather than merely collecting files. Someone should be able to determine which skill they should use and why that version is trusted.

See What Is an AI Skill Registry?.

Skill owner

A skill owner is the person or team accountable for maintaining a reusable AI skill over time.

The original author is not always the right long-term owner. A developer may create a skill for reviewing security questionnaires, while Security or Sales Engineering ultimately owns the underlying process.

Ownership should answer a practical question: when the instructions become outdated, an exception appears, or a new version needs review, who is responsible for deciding what happens next?

Skill provenance

Skill provenance is the record of where a skill came from and how it reached its current state.

Useful provenance can include the original repository, provider, author, imported package, parent version, source URL, commit, content hash, or other evidence connecting the current artifact to its history.

Provenance does not prove that a skill is safe or correct. It gives reviewers context about what they are evaluating and helps distinguish an internally maintained asset from an unknown external copy.

Skill version

A skill version is a specific revision of a skill.

Versioning gives a team something stable to review and approve. If version 2.1 was reviewed and someone changes the instructions, scripts, or supporting files, the resulting version should be treated as a new revision rather than silently inheriting the earlier approval.

The important question is not merely whether a version number exists. It is whether the organization can identify the exact content that was tested, reviewed, approved, and distributed.

See Versioning and Comparing Changes.

Approved version

An approved version is the specific revision of a skill that has completed the organization's required review for a defined use.

Approval should attach to an identifiable version, not just to the skill's name. Saying that “Contract Review is approved” becomes ambiguous as soon as Contract Review changes.

Approval also has scope. A version reviewed for internal drafting may not automatically be approved to send customer communications, access additional systems, or take external actions.

Latest version

The latest version is the newest available revision of a skill.

Latest and approved are different concepts. The newest revision may still be under development or review, while an earlier version remains the supported version for production use.

Some AI platforms provide native mechanisms for selecting a default, latest, or explicit version. Organizations should use those controls where they fit and maintain a clear policy for which version a workflow is expected to use.

Skill distribution

Skill distribution is the process of making a skill version available to the people, systems, repositories, or AI platforms that need it.

Publishing a new version at the source does not necessarily establish that every downstream user is now using it. Copies may exist in repositories, provider accounts, local directories, internal tools, or other systems.

A useful distribution record answers where the version was sent and what was verified. Availability and actual usage are separate questions.

Version drift

Version drift occurs when different users or systems are relying on different revisions of what is intended to be the same reusable skill.

For example, an owner fixes an error in a shared skill and approves version 2.2, while another team continues using a copied version 2.0. Both groups may believe they are using the same skill even though the behavior has diverged.

Drift is not automatically a problem. Teams may maintain intentional variants. The management problem is being unable to tell whether the difference is deliberate, approved, or simply stale.

Skill variant

A skill variant is a deliberately adapted version of a reusable skill for a different team, environment, provider, or use case.

A procurement team, for example, may adapt a customer-security skill because its evidence requirements and escalation rules differ. That can be legitimate.

A useful system keeps the relationship to the source visible while allowing the variant to have its own owner, review state, tests, and lifecycle.

Skill review

A skill review is the evaluation of a specific skill version before broader or more consequential use.

Review can include business correctness, security, permissions, data handling, scripts, dependencies, external communication, expected failure behavior, and representative tests.

The amount of review should match the work. A formatting helper used by one person does not need the same process as a shared skill that prepares customer-facing statements or can modify production data.

Skill security scanning

Skill security scanning is the analysis of a skill package for potentially unsafe or malicious behavior.

Scanning may look for suspicious instructions, executable content, external network access, dangerous tool use, hidden dependencies, or other risk indicators.

Security scanning can support governance, but it is not the whole governance process. A skill can contain no malicious behavior and still be outdated, incorrect, poorly owned, distributed to the wrong audience, or using the wrong approved version.

Trust status

A trust status describes where a skill version sits in the organization's review and lifecycle process.

Typical states can include Draft, In Review, Approved, Blocked, or Deprecated. The exact names matter less than making the meaning clear.

Trust status should describe a version's governance state. It should not be treated as a universal claim that the skill is safe or correct in every environment.

Skill lifecycle

The skill lifecycle is the sequence through which a reusable skill moves from experimentation to shared use and eventually retirement.

A practical lifecycle might include creation, testing, review, approval, distribution, monitoring, revision, deprecation, and withdrawal.

The process should make experimentation easy while giving shared or consequential work enough structure that the next person can understand what they are using.

Shadow AI skill

A shadow AI skill is a reusable AI instruction set or workflow being used inside an organization without being part of the organization's known or supported management process.

The term does not imply malicious behavior. A useful skill often becomes “shadow” simply because someone created it to solve a problem, shared it with colleagues, and adoption grew faster than the management process around it.

The first useful step is visibility: understand what people are relying on before deciding what needs formal governance.

Commonset

A Commonset is a governed collection of reusable AI capabilities available to a defined audience.

An inventory can contain experiments, deprecated versions, restricted assets, and unfinished work. A Commonset answers a more practical question: which capabilities belong in the trusted, usable set for this team?

For example, an Engineering Commonset and Finance Commonset may contain different capabilities even though both belong to the same organization.

A practical way to use this glossary

The terminology becomes useful when it helps a team answer concrete questions about a shared skill:

• What capability does this skill implement?
• Who owns it?
• Where did it come from?
• Which exact version was reviewed?
• Which version is approved now?
• Who is allowed to use it?
• Where has that version been distributed?
• Are downstream copies still aligned?
• What should happen when the underlying process changes?

If those answers depend entirely on asking the person who originally built the skill, the organization has accumulated reusable AI work without yet creating a durable management layer around it.

For a practical operating model, see Managing Claude Skills Across an Enterprise.