Agent Skills Move to Neutral Governance. The Format Still Needs Careful Review

A shared file format can make agent know-how easier to move between products. It cannot make the instructions inside that file safe, compatible or correct. That distinction matters as Anthropic moves Agent Skills into the Linux Foundation’s Agentic AI Foundation (AAIF), where the format will sit alongside other projects intended to make agent systems work across vendors.

What changed on October 22

Anthropic announced that it is donating the Agent Skills name and logo, the GitHub organization and the agentskills.io domain to AAIF. The company says engineers from Anthropic, Google, OpenAI and other companies will maintain the standard as individuals, with David Soria Parra and Mahesh Murag as lead maintainers. Anthropic says developers may continue to use and contribute to the format without joining the foundation. ^[1]

AAIF announced four contributed projects at its October 22 conference: Agent Skills from Anthropic, Open Responses from OpenAI, OpenEnv from Hugging Face and OpenSandbox from Alibaba. The foundation describes these as separate layers of the agent stack, from reusable capabilities and model interfaces to training environments and execution sandboxes. AAIF said the additions bring its hosted project count from three to ten in its first year. ^[2]

The timing is a governance change, not a newly released technical capability. Anthropic says Agent Skills has been an open standard since December 2025 and reports that more than 70 platforms have integrated it. Those adoption counts are the company’s figures; they do not mean every client implements every optional field or loads a skill the same way. ^[1]

A small package can carry a lot of behavior

The format is deliberately plain. A skill is a directory with a required SKILL.md containing YAML metadata and Markdown instructions. Optional sibling folders can hold scripts, reference material and assets. An agent can discover the skill, read its description, and load its longer instructions when a relevant task arrives. ^[3]

That structure is useful because procedural expertise often fits better in a file package than in a model prompt that must be repeated on every request. A support team could keep its escalation procedure in one skill folder; an engineering group could package a release checklist and helper script. When a compatible client can read the same package, the workflow is easier to share and update.

But a skill is executable guidance in a broad sense. It may tell an agent to run commands, read files, contact services or transform data. The format does not sandbox those actions, verify an author’s identity, or judge whether a procedure is appropriate for a given user. The integration guide explicitly leaves important choices to each client: where skills live, how they are discovered, and whether the model reads files directly or receives content through a tool. ^[4]

This is why “portable” should be read narrowly. The same folder can be understood by multiple implementations, but its behavior can still vary with supported metadata, filesystem access, available commands, approval prompts and network policy. The human and organizational review around a skill remains essential.

What neutral stewardship can improve

A foundation can make it easier for users who depend on the format to influence its future without relying on one vendor’s product roadmap. It can also provide a visible process for changes, compatibility discussions and security guidance. Anthropic says its initial proposed roadmap includes versioned releases, a formal proposal process and security guidance for skill authors and installers. These are proposals, not completed governance rules. ^[1]

The project’s design should remain modest. Its specification says what belongs in a skill package; it does not dictate one directory layout for every client or prescribe a universal permission model. Keeping those boundaries clear helps avoid treating one product’s implementation choice as a requirement of the standard. ^[3]

For teams building agent platforms, the practical opportunity is to agree on a reliable minimum: validate metadata, show a skill’s origin, load instructions on demand, expose which tools it may invoke, and make bundled code visible to reviewers. These are implementation choices that can increase user confidence even when the file format itself stays small.

A review checklist for existing skills

Before installing a skill from a registry or repository:

1. Read the full SKILL.md, including any nested references it directs the agent to load.
2. Inspect scripts and assets as code. Look for shell commands, network calls, file writes and credential handling.
3. Check who maintains the source and what license applies. A public repository is not an endorsement.
4. Confirm which client versions discover the skill and what metadata they honor. Test the same package in the deployment where it will run.
5. Restrict file, network and tool permissions to the task. A procedural shortcut should not silently expand an agent’s authority.
6. Keep a version or commit reference so updates can be reviewed rather than accepted invisibly.

The goal is not to turn every skill into a software supply-chain project. It is to recognize that reusable instructions can shape real actions. A shared syntax makes reuse cheaper; that makes provenance and review more valuable.

What to watch next

The donation’s impact will depend on the work that follows: whether the community gets a public proposal process, how incompatible client behaviors are documented, and whether security guidance covers both instruction text and bundled code. The announced roadmap identifies these subjects but does not settle them. ^[1]

Developers can continue using the format today and follow the Agent Skills specification as the project moves under AAIF. Teams comparing agent integration layers may also find our MCP explainer useful: protocols connect tools, while skills package the procedures that tell an agent how to approach work.

The useful promise here is interoperability through a small, readable package. Its limit is equally important: no file convention substitutes for sandboxing, least privilege or human review.