Imagine an AI assistant preparing a proposal. It selects the right skill, follows the instructions and includes a convincing client reference. Unfortunately, that reference is no longer approved for external use.
Nothing crashed. The output looks professional. The assistant followed instructions that somebody forgot to maintain.
That is a governance problem worth solving before a handful of useful skills becomes an organisational dependency. Reusable instructions need owners, versions and review deadlines. When a review is overdue, the user should see it.
An expiry date does not mean the content becomes wrong at midnight. It means someone is due to take responsibility for checking it.
Different skills, different maintenance needs
Skills can describe a working method, provide specialist knowledge or shape how an assistant communicates. The following is a practical classification, not an official taxonomy. A single skill can serve several purposes.
| Skill type | Purpose | Example |
|---|---|---|
| Workflow skill | Defines how to perform a repeatable task | Sales Opportunity Qualification |
| Domain knowledge skill | Supplies specialist facts and terminology | Energy Market Knowledge |
| Context skill | Provides organisational, customer or personal context | Our Company Positioning |
| Standards and policy skill | Defines mandatory rules and constraints | Security Standards or Architecture Standards |
| Style and communication skill | Guides tone, language and presentation | Personal or Company Writing Style |
| Review and evaluation skill | Assesses work against explicit criteria | Tender Review or ARA Review |
| Tool-enabled skill | Guides the use of connected tools | Sales Research using CRM and web search |
| Reference skill | Validates the solution against reference requirements and the approved purpose for references. | COMPANY Customer References Skill |
Consider a Financial Reporting Rules skill. Definitions for turnover and profit should be approved centrally and applied before calculations start. They may remain unchanged for years, but a change in reporting policy should trigger an immediate review.
A Company Strategy and Vision skill needs attention when leadership changes direction. A Customer Project References skill could have a 90-day review cycle, with earlier updates when a project changes or permission to use a reference is withdrawn.
Communication guidance has different maintenance needs. A Cross-Cultural Communication skill supporting European and Asian teams should reflect the people and working relationships involved, rather than treating two continents as personality types. Feedback from those teams can matter more than a calendar reminder.
Review frequency should reflect both the likelihood of change and the consequences of being wrong. Even a skill that remains within its review period may need an urgent correction. However, the Customer References skill needs a more frequent update and affirmation compared to the cross-cultural communication skills.
OpenAI’s skill metadata is necessary, but not enough
OpenAI’s guide to building skills describes a SKILL.md file with a name, description and workflow instructions, supported by optional resources. The name identifies the skill; the description helps the model decide when to use it.
The broader Agent Skills specification defines these frontmatter fields:
| Field | Requirement | Purpose |
|---|---|---|
name | Required | Identifies the skill; matches its directory name |
description | Required | Explains its purpose and activation conditions |
license | Optional | Identifies licensing terms |
compatibility | Optional | Describes environment requirements |
metadata | Optional | Holds additional string key-value pairs |
allowed-tools | Optional, experimental | Lists pre-approved tools; support varies by implementation |
The specification explicitly provides a metadata extension field. It recommends distinctive key names to avoid conflicts and gives author and version as examples.
There is therefore no need to invent a competing format. Use the extension point already provided. What the specification does not supply is a company policy defining who approves a skill, how often it needs review or what happens when that review is overdue.
The following metadata comes from our Company Writing Style skill:
metadata:
amis-governance-policy: "amis-skill-governance/v1"
amis-owner: "Pieter de Schrijver"
amis-maintainer: "Robbrecht van Amerongen"
amis-version: "1.1.0"
amis-created: "2026-07-13"
amis-last-reviewed: "2026-09-09"
amis-review-by: "2027-09-07"
amis-status: "active"
amis-risk-tier: "low"
amis-validation-level: "content"
amis-source-of-truth: "SKILL.md;references"
The amis- prefix distinguishes these company-specific properties. Their keys and values are strings, as the specification requires for this mapping. Another organisation can use its own prefix and schema.
The owner is accountable for the content. The maintainer handles changes and reviews. They may be the same person, but recording both roles makes responsibility visible. The review deadline sets an obligation to reassess the content; it is not a guarantee that nothing will change before then.
Give the governance rules one home
The COMPANY Skill Governance Skill holds the shared policy. Individual skills carry the metadata. Copying the same lifecycle instructions into every skill would simply create another maintenance problem.
In this example, a deterministic validator checks required fields, version and date formats, review periods and declared source paths. A check on 9 September 2026 found Personal Writing Style version 1.1.0 structurally valid, with no findings. Its declared lifecycle status was active, validation level content, and next review deadline 7 September 2027.
Those are different kinds of evidence. Structural validation checks the metadata and files. Content review assesses the instructions. Source verification checks material claims against authoritative sources. A successful parser run cannot perform the other two jobs.
With that distinction preserved, a user can ask: “Who owns Company Writing Style, who maintains it, and when is its next review due?” The answer should come from the skill’s metadata, with missing information reported rather than guessed.
Warn before use, without blocking the task
For an otherwise permitted skill, an overdue review should produce a visible warning and allow the task to continue. The user needs to know what requires attention and who is responsible for it.
The following Markdown is an example policy section for the COMPANY Skill Governance Skill. It defines a non-blocking review warning; it is not executable enforcement code.
## Non-blocking review-by check
Before applying a governed skill:
1. Read its name and these metadata fields:
`amis-version`, `amis-review-by`, `amis-owner`,
`amis-maintainer`, `amis-status`, `amis-validation-level`.
2. Obtain today's date from the runtime. Parse `amis-review-by`
as YYYY-MM-DD. The review is overdue only when today is
later than that date.
3. If overdue, show this notice before the skill's output:
> **Skill review overdue: [skill name] — version [version]**
> Review deadline: [review-by date].
> Owner: [owner]. Maintainer: [maintainer].
> Declared validation level: [validation level].
> Continuing with your request. The owner needs to arrange
> a review; the content may require updating.
4. If the date is missing or invalid, or today's date is
unavailable, warn that review currency cannot be verified.
Report missing ownership information; do not invent it.
5. Do not block usage solely because the review is overdue
or cannot be verified. Preserve all separate safety,
access and lifecycle restrictions, including retirement.
6. Do not silently renew review dates, change approval status
or claim the owner has been notified. A warning to the user
is not a notification to the owner.
For an illustrative Customer Project References skill, the user would see:
Skill review overdue: Customer Project References — version 2.3.0
Review deadline: 1 September 2026.
Owner: Head of Sales. Maintainer: Portfolio Marketing Lead.
Declared validation level: content.
Continuing with your request. The owner needs to arrange a review; the content may require updating.
The assistant then provides the requested result. The user can decide whether the reference needs confirmation before publication. A separate owner-notification workflow can be added, but it should actually send and record the notification before claiming to have done so.
Make the check unavoidable, not the skill unusable
Writing “before applying a skill” in a Markdown file does not make that file load automatically. In a conversational setup, the governing instructions must explicitly invoke the COMPANY Skill Governance Skill. This remains an instruction to the model, not a technical guarantee.
For dependable enforcement, put a deterministic check in the application’s skill-loading path and have the application display the warning. CI/CD can check metadata before publication, while scheduled checks can identify reviews approaching their deadline. Neither replaces a runtime check: a skill can pass validation on release day and become overdue months later.
Authorisation also needs more than metadata. An amis-owner value identifies a person; it does not prove that person approved this version. Keep approval evidence in an access-controlled review or release process, linked to the exact skill version. Only authorised maintainers should be able to publish changes.
Before rollout, test the ordinary cases: a current skill, one due today, an overdue skill and one with missing metadata. Confirm that warnings appear, permitted work continues, and independent restrictions still apply.
The practical starting point is small. Take the skills already influencing important work. Assign their owners, agree their review intervals and make overdue reviews visible wherever those skills are used. Then give the owners a process for resolving them. Otherwise, the warning will become just another message everyone learns to ignore.
