Agent Skills moves to AAIF with a roadmap for shared governance

Anthropic announced on October 22 that it is donating Agent Skills to the Agentic AI Foundation under the Linux Foundation. The transfer includes the standard’s name and logo, GitHub organization and agentskills.io domain. Users and contributors do not need to join the foundation to participate. Anthropic’s announcement describes a change in stewardship, not a new Claude model or an automatic upgrade to installed agents.

For teams building reusable agent workflows, the practical question is what this makes portable and what remains specific to each product. A shared format can reduce the work of packaging instructions again for another client. It does not establish that every client will choose the same skill, run the same tools or produce the same result.

What the donation changes

Engineers from Anthropic, Google, OpenAI and other companies will maintain the standard as individuals. David Soria Parra and Mahesh Murag are the lead maintainers. Anthropic has proposed a roadmap covering versioned releases, a formal proposal process and security guidance for skill authors and users. These are proposed next steps, not a claim that a new release process or security certification is already available.

The distinction matters when planning adoption. A team can track future specification decisions separately from its own deployment approvals. Moving a project’s assets into a foundation does not itself demonstrate that a particular downloaded skill is trustworthy or useful.

The portable part is a package of instructions

The Agent Skills overview describes a folder built around SKILL.md, with optional scripts, reference documents and other resources. Clients initially read a skill’s name and description, then load its full instructions when it becomes relevant. Supporting material can be loaded when needed. This is a method for supplying procedural context, rather than retraining the underlying model.

The format specification requires a name and description in YAML metadata followed by Markdown instructions. A compatibility field can describe required software, network access or the intended environment. The specification also labels its optional tool permission field experimental and warns that implementations may support it differently.

That gives authors a useful boundary for portability claims. A folder can satisfy the format while depending on a command or service that another agent cannot access. The reference validator checks metadata and naming rules. Passing that check is not a test of the workflow’s output quality.

Loading a skill is also a trust decision

The client implementation guide distinguishes skills found in a project from those installed for a user. It recommends a trust check before loading project skills because a newly obtained repository may contain untrusted instructions. It also describes different discovery arrangements for local agents and remote or sandboxed systems. A remote agent cannot simply assume it can read a user’s local skill folder.

These details make client behavior worth checking before migration. Ask where the client discovers skills, which source wins when names collide and how bundled scripts receive permission to run. The guide calls for deterministic handling of collisions. These are integration decisions, not properties guaranteed merely by the presence of SKILL.md.

Our coverage of skill pinning in LangChain Deep Agents illustrates the same distinction. Application control over which instructions load is separate from verifying a caller’s authority to use a tool. A reusable instruction package should not be mistaken for permission to access a system.

Test the workflow rather than the label

The project’s evaluation guide recommends running realistic tasks with a skill and without it, or against a previous version. Each run should start with clean context. Test prompts should vary in wording and include an edge case, rather than repeatedly demonstrating the easiest example.

For an organization moving a document workflow between agents, a useful comparison would keep the input files and expected result fixed. Record whether required content survives, whether the output file is usable and how much time or model context the run consumes. These are suggested acceptance checks, not results from testing conducted for this article.

The guide also separates verifiable assertions from qualities that need human review. A file can meet structural checks while still being confusing or poorly written. This is why successful installation and one attractive example are weaker evidence than repeatable results across the tasks the team actually needs.

How to participate without joining the foundation

The current contribution guide directs concrete bugs to GitHub Issues and specification proposals or questions to Discussions. It asks proposals to address observed implementation problems. It also says the repository is not accepting community skill submissions or major architectural redesigns at present. An open standard is therefore not the same thing as a central marketplace for everyone’s skills.

Contributors using AI assistance must disclose it, except for trivial spacing or typo fixes. For teams that only want to use the format, the immediate work is simpler. Document dependencies, inspect the resources a skill includes and test its behavior in the intended client. Watch the proposed roadmap for actual changes before treating future governance or security work as shipped functionality.

Illustrative archival photograph of pair programming in April 2007 by Lisamarie Babik via Wikimedia Commons, under Creative Commons Attribution 2.0. Resized proportionally and converted to WebP. The people pictured are not identified as Agent Skills maintainers.