Anthropic Donates Agent Skills to the Linux Foundation’s AAIF

Anthropic moved Agent Skills into AAIF on October 22

Anthropic announced on October 22, 2026 that it is donating Agent Skills to the Agentic AI Foundation, an organization hosted by the Linux Foundation. The transfer covers the standard as well as the Agent Skills name and logo, GitHub organization and agentskills.io domain. AAIF’s live project directory now lists Agent Skills and links to the project repository and website.

The practical change is governance, not a new model or paid API. The specification and repository remain publicly accessible, and Anthropic says developers can use or contribute to the standard without joining AAIF. The announcement names David Soria Parra and Mahesh Murag as lead maintainers and says engineers from Anthropic, Google, OpenAI and other companies will maintain the project as individuals.

The available artifact is a small file-based contract

A conforming skill is a directory with a required SKILL.md file. That file combines YAML frontmatter with Markdown instructions. The specification requires a lowercase name and a non-empty description; it also defines optional fields including license, compatibility, metadata and allowed-tools. A skill can carry scripts, references, templates and other assets alongside the instruction file.

Clients can first load only names and descriptions, then read a full SKILL.md when a task matches, and finally open referenced resources or run bundled code if needed. That progressive-disclosure pattern can keep discovery cheap, but it is not a universal runtime contract. The specification packages procedural context; each client still decides how it discovers, interprets and executes a skill.

Adoption is material if Anthropic’s figures hold

Anthropic says more than 70 agent platforms—including ChatGPT, Cursor, GitHub Copilot and VS Code—have integrated Agent Skills since the standard was published in December 2025. It also reports one million published skills and nearly 280 million installs. Those figures explain why a neutral project home matters: the format is no longer only an implementation detail for Claude Code.

AccessAllGPT could verify the public specification, repository and AAIF listing, but not the complete integration roster, deduplication method, definition of “published,” installation telemetry or active usage behind those totals. Treat the numbers as vendor-reported ecosystem evidence, not proof that a given skill works consistently across 70 clients or that installations represent production use.

The governance promise is ahead of the governance machinery

Anthropic proposes a roadmap with versioned releases, a formal proposal process and security guidance for skill authors and installers. Those are sensible priorities, but the announcement describes them as what comes next. The donation should not be reported as if those controls, compatibility policies or release guarantees are already complete.

A Linux Foundation home can reduce single-vendor control over the name and specification. It does not resolve how incompatible client behavior will be tested, how breaking changes will be signaled, which conformance suite will be authoritative, how disputes will be decided or how quickly unsafe ecosystem patterns will produce normative guidance. Builders should watch the repository and AAIF process for actual version and governance artifacts.

Portability stops where client behavior begins

A portable folder is useful, but identical files do not imply identical outcomes. Clients may expose different tools, parse optional metadata differently, truncate instructions at different context limits, resolve references from different working directories, prompt for approval at different moments or decline fields they do not support. Model and system-prompt differences add another source of behavioral drift.

Test the same pinned skill on each intended client with the same representative cases. Record discovery, selected skill, files read, scripts invoked, tool arguments, approvals, outputs and errors. A skill that passes in one agent should remain unapproved elsewhere until the second client reproduces the required behavior and control evidence.

Bundled instructions and scripts remain a supply-chain boundary

The format can bundle executable scripts and can tell an agent which references or assets to load. That makes a skill more capable than a static prompt, but also means review cannot stop at SKILL.md. A repository owner can change a referenced file, a script can reach local data or networks under the host process’s authority, and natural-language instructions can request tools beyond what a reviewer expected.

Pin an immutable revision or verified package, inventory every bundled file and transitive dependency, scan executable content, restrict filesystem and network access, and enforce tool authorization in trusted application code. Treat allowed-tools metadata as descriptive input to a client policy—not as proof that the skill cannot ask for or obtain broader authority. Re-review on any content, dependency, client or model change.

There is no price, SLA or conformance guarantee to buy

The announcement introduces no hosted Agent Skills service, paid tier, model identifier, API price or service-level agreement. The project repository is public and GitHub identifies it as Apache-2.0 licensed. Costs arise from the chosen agent client, models, tools, skill review, testing and operations rather than a fee defined by this standard announcement.

Teams comparing this with a vendor-specific extension system should therefore evaluate governance participation, client coverage, behavioral portability, update controls and review cost—not search for a nonexistent per-token rate. A public specification and permissive repository license make implementation possible; they do not require a client vendor to support every field or guarantee long-term compatibility.

What agent teams should do next

Use Agent Skills when reusable procedural knowledge must move between supported clients and the team can own the review boundary. Start with one low-authority skill, pin the repository state, validate its metadata, test discovery and execution on every target client, and keep sensitive credentials and consequential permissions out of the skill package. Preserve traces that show which revision and resources produced each result.

Constrain adoption to read-only or draft-only work while cross-client behavior, update provenance or script isolation remains uncertain. Wait for concrete versioning and governance artifacts when compatibility stability is mandatory. Reject a skill when its source cannot be pinned, its bundled code cannot be reviewed, or it depends on broad authority that the host cannot enforce independently of model instructions.

Disclosures

AccessAllGPT received no Anthropic, Linux Foundation, AAIF or client access, private briefing, telemetry, skill package, governance role, payment or compensation for this article. Anthropic’s adoption figures are reported as vendor claims and were not independently verified. No cited organization sponsored, reviewed or endorsed this work. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with Anthropic, the Linux Foundation, AAIF or organizations cited. Publication-wide relationships are listed on the disclosures page.