Agent SkillsAAIFSKILL.mdAI Agent

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.

Agent Skills Now Has Shared Rules for Maintaining the Standard

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:

RolePrimary responsibility
ContributorsIssues, changes, and discussion
MaintainersSpecific areas such as documentation or the reference library
Core MaintainersSubstantive specification changes, releases, and overall direction
Lead MaintainersFinal 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 October donation and November governance document inform current team maintenance

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.

LayerWhat travelsWhat the destination must verify
ProcedureSteps, decision rules, output requirementsDiscovery and loading of the intended skill
ResourcesRelative references, scripts, templatesComplete files and a suitable runtime
ExecutionDescriptions of required tools and servicesActual tools, credentials, network access, and authorization

Format and resources can travel; the destination still supplies tools and permissions

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

Record origin, prerequisites, public fixtures, and actual host results before approving an update

Start with a lightweight record:

  1. Origin and version: source repository, pinned commit, local changes, and responsible maintainer.
  2. Prerequisites: files, commands, services, authorization, and host-specific extensions.
  3. Public fixtures: fixed input, expected output, and actions that should remain out of scope.
  4. 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.

Related posts

T3 Code Provider Switches: What Context Carries Over?
T3 CodeContextModel Switching

T3 Code Provider Switches: What Context Carries Over?

Keep a T3 Code task moving after a provider switch. Understand v0.1.7's selected history, context allowance, attachment limits, and runtime boundaries, then verify the receiving agent can continue.

Run your Agent workflow through Nbility

Get an API key and connect OpenAI-compatible models and developer tools from one place.

Get an API key