Agent Skills Now Has Shared Rules for Maintaining the Standard
AAIF stewardship and November's governance document clarify how Agent Skills evolves. Learn what travels between hosts and what teams still need to version and verify.

Teams using several agents often want to share the same working methods: preparing release notes, checking sources, or accepting a change. Agent Skills packages those methods into portable directories. The people maintaining that format now have a more explicit shared decision process.
Anthropic announced the donation of Agent Skills to the Agentic AI Foundation (AAIF) on October 22. The project adopted a governance document on November 4. For a team maintaining skills, the practical questions are how the standard will evolve, how local copies should follow it, and what still needs checking on each host.
We checked the donation announcement, specification, and governance document on November 11, 2026. We did not install or run the example across hosts, report compatibility rates, or treat announcement installation figures as evidence that a particular skill is reliable.
What changed in stewardship
The donation covers the Agent Skills name and logo, GitHub organization, domain, and ongoing stewardship of the standard. Using or contributing to it does not require AAIF membership. Maintainers participate as individuals rather than through guaranteed company seats.
The November 4 document assigns responsibilities:
| Role | Primary responsibility |
|---|---|
| Contributors | Issues, changes, and discussion |
| Maintainers | Specific areas such as documentation or the reference library |
| Core Maintainers | Substantive specification changes, releases, and overall direction |
| Lead Maintainers | Final authority, including disputed decisions and vetoes |
Lead and Core Maintainers form the technical steering committee. Consensus is preferred, with defined voting and escalation when it fails. Open participation does not mean every decision is an equal vote of every participant.
The significance goes beyond another product announcing Skills support: the format has named responsibilities and a public change process. Governance also describes tagged specification releases, changelogs, and a formal proposal track. Some provisions are conditional on that track being established; they do not prove an entire versioning system already exists today.
Portable knowledge still needs a working host
The core format remains a directory containing SKILL.md: YAML metadata followed by Markdown instructions, with required name and description fields and optional scripts, references, or templates.
That simplicity helps portability, but execution has additional dependencies.
| Layer | What travels | What the destination must verify |
|---|---|---|
| Procedure | Steps, decision rules, output requirements | Discovery and loading of the intended skill |
| Resources | Relative references, scripts, templates | Complete files and a suitable runtime |
| Execution | Descriptions of required tools and services | Actual tools, credentials, network access, and authorization |
A release skill cannot grant another host GitHub access by mentioning publication. Copying a Python script does not install Python. The compatibility field can describe prerequisites. Experimental allowed-tools support varies between implementations and is not a universal permission switch.
For persistent project rules versus on-demand procedures, see the instruction-file and Skills explanation. For external tools, see MCP. Naming a tool inside instructions does not connect its server.
Keep a shared skill small and explicit
This example organizes a supplied public change list. It illustrates the format; we have not installed it, tested automatic activation, or verified it across hosts:
---
name: public-release-brief
description: Turn a supplied public change list into a release brief. Use when drafting release notes from public material.
compatibility: Requires access to the supplied public change list and Markdown output.
metadata:
owner: docs-team
revision: "1"
---
# Public release brief
1. Read the supplied public change list and its source links.
2. Group confirmed changes into Added, Fixed, and Breaking changes.
3. Include only details supported by the supplied material.
4. Return Markdown and list any facts that still need verification.
5. Publication, commits, and messages require a separate authorized task.
The parent directory should be public-release-brief, matching name. Reference files relative to that directory rather than using one machine's absolute paths. Explain when to activate the skill in its description, then put actionable steps and acceptance criteria in its body.
metadata.revision here is a team convention, not a specification version or a universally interpreted host setting. Check the skill's own license too: an open standard does not automatically license every third-party skill, script, or attached asset under the same terms.
Retain four kinds of maintenance evidence
Start with a lightweight record:
- Origin and version: source repository, pinned commit, local changes, and responsible maintainer.
- Prerequisites: files, commands, services, authorization, and host-specific extensions.
- Public fixtures: fixed input, expected output, and actions that should remain out of scope.
- Host results: product and version, with discovery, loading, resource access, and full execution recorded separately.
A format validator establishes structural validity. It cannot establish correct task interpretation, safe scripts, or identical behavior on all hosts. Begin a migration with public read-only work or a returned draft, then configure write capabilities as the authorized task requires. The tool-output permission discussion explains a related execution boundary.
When upstream changes, inspect descriptions, scripts, and permission requirements, then repeat the public fixture. Avoid replacing an entire working collection solely because an upstream revision changed; also avoid keeping copies with no traceable origin.
For model access, use the client directory and connection guide. Nbility supplies that model-access layer. Skill discovery, execution tools, and authorization still belong to the host. Those distinctions make a shared procedure maintainable after its first installation.


