On October 22, 2026, at AGNTCon + MCPCon North America in San Jose, the Agentic AI Foundation announced four new projects. The one that touches every team running coding agents is Agent Skills, the SKILL.md format, contributed by Anthropic. The other three are Open Responses from OpenAI, OpenEnv from Hugging Face, and OpenSandbox from Alibaba. The foundation, which sits under the Linux Foundation, now hosts 10 projects, including MCP, A2A, AGENTS.md, and goose.
Anthropic’s donation post lists what moved: the Agent Skills name and logo, the GitHub organization, the agentskills.io domain, and the standard itself. It also gives the adoption figures, which are Anthropic’s own: more than 70 agent platforms have integrated Agent Skills since the standard was published in December 2025, and “1 million skills have been published and nearly 280 million installed.”
It reads like governance news, and mostly it is. But it settles a practical question for anyone with Claude Code on one task and Codex on another: is a skill a vendor feature or a format you can standardize on? Now it is a format with a neutral owner.
TL;DR
Agent Skills is now a vendor-neutral project at the Agentic AI Foundation, maintained by engineers from Anthropic, Google, OpenAI, and other companies acting as individuals. Nothing about the file format changed on October 22. Your existing SKILL.md files still work, and the products that load them still load them from the same places. What changed is who decides the next version. For a team, the useful move is to write skills against the six spec fields only, keep one copy per repository, and let each agent find it.
Agent Skills in one section
A skill is a directory with a SKILL.md file: YAML frontmatter with at least a name and a description, then Markdown instructions. It can carry scripts/, references/, and assets/ alongside. The specification is short enough to read in ten minutes.
Skills stay cheap through progressive disclosure. An agent loads only each skill’s name and description at startup, about 100 tokens each per the spec, reads the full SKILL.md body when a task matches, and opens bundled files only when the instructions point at them.
For the longer explanation and how to vet skills from public sources, see what a coding agent Skill is.
What the move changes, and what it doesn’t
| Before October 22 | After | |
|---|---|---|
| Owner of name, logo, GitHub org, domain | Anthropic | Agentic AI Foundation |
| Maintainers | Published under Anthropic’s org | Engineers from Anthropic, Google, OpenAI, and others, as individuals; David Soria Parra and Mahesh Murag are named Lead Maintainers |
The SKILL.md format |
Spec at agentskills.io | Same spec, same URL |
| Where products look for skills | Each product’s choice | Still each product’s choice |
| Product-specific extensions | Per product | Still per product |
| Roadmap | Not formalized | Anthropic proposes versioned releases, a formal proposal process, and security guidance for skill writers and installers |
Three things change. First, ownership of the brand and the infrastructure: the name, the domain, and the GitHub organization no longer belong to the vendor whose product competes with the others that read the format. Second, the people at the table. Engineers from Anthropic, Google, and OpenAI now maintain one format their products already read. Third, a process is coming, and you do not need to join the foundation to take part in it.
Three things do not change, and they are the ones that affect your repository. The format is the same file it was on October 21. The spec still does not say where skills live; it defines what goes inside a skill directory, and each product decides which directories it scans. And product extensions stay product extensions: a field one agent understands is still a field the next one may reject.
One detail shows how fresh this is. On October 26 the repository’s contributing guide still said logo requests “are reviewed by the Anthropic team,” and the spec page carried no version number. Versioned releases are on the proposed roadmap, not shipped. Treat the spec as stable in practice and unversioned on paper.
Write a skill once, load it in more than one agent
Here is a minimal skill that matches the spec exactly. The name is lowercase letters, numbers, and hyphens, at most 64 characters, and it matches the folder name. The description says what the skill does and when to use it, inside the 1,024-character limit. Every other field is optional.
.agents/skills/migration-review/
├── SKILL.md
└── references/
└── CHECKLIST.md
---
name: migration-review
description: Reviews a database migration before it merges. Checks reversibility, locking on large tables, and data backfills. Use when a diff adds or changes files under migrations/ or the user asks for a migration review.
license: Apache-2.0
metadata:
owner: platform-team
version: "1.2"
---
# Migration review
1. List every migration file in the diff.
2. For each one, confirm a down migration exists, or state why it cannot.
3. Flag any ALTER TABLE on a table listed in references/CHECKLIST.md as large.
4. Flag backfills that run inside the migration instead of a separate job.
5. Report one line per file: PASS, or FAIL with the reason.
Do not edit the migration. Report only.
The metadata values are quoted strings because the spec defines metadata as a map of string keys to string values. The reference file sits one level below SKILL.md, which is what the spec recommends. Check it with the reference validator before anyone else depends on it:
skills-ref validate ./.agents/skills/migration-review
Now the part the foundation does not solve: discovery paths. Codex’s skills docs list .agents/skills in the repository and $HOME/.agents/skills for the user. Claude Code’s docs list .claude/skills/<skill-name>/SKILL.md for a project and ~/.claude/skills/ for a person. Both follow symlinked skill folders. So keep one real copy under .agents/skills, the cross-client convention the spec’s client implementation guide recommends scanning, and link it for Claude Code:
mkdir -p .claude/skills
ln -s ../../.agents/skills/migration-review .claude/skills/migration-review
git add .agents/skills .claude/skills
One folder, one review, one place to update. Products that scan .agents/skills directly need no link; check each one’s docs.
Three rules keep a skill portable:
- Use only the six spec fields (
name,description,license,compatibility,metadata,allowed-tools) in the shared copy. Claude Code’s docs say claude.ai uploads and the Skills API reject any other key with a hard error, while Claude Code itself accepts extensions likecontext: fork. - Treat
allowed-toolsas a hint. The spec marks it experimental, and support varies between agents. - Keep product-specific config out of the shared frontmatter. Codex reads optional UI and invocation settings from an
agents/openai.yamlfile inside the skill folder, which other agents ignore.
Standardize on the shared format when more than one agent, or more than one person, touches the same repository. Skip the ceremony when one developer runs one agent: a personal skill in that agent’s own directory is fine, and portability can wait until a second agent shows up.
The trust question does not move to the foundation
A neutral owner for the format does not make any skill safe. The client implementation guide points out that project-level skills come from the repository being worked on, which may be a fresh clone of something you do not control, and suggests agents gate those skills on a trust check. Anthropic’s proposed roadmap includes security guidance for people who write and install skills, which says the guidance does not exist yet in finished form.
Until it does, review a skill like a dependency: read SKILL.md and every script before an agent runs it, keep commands least-privileged, and keep secrets out. With 1 million skills published by Anthropic’s count, supply is not the constraint. Review is.
Where Sharkly fits
A shared format answers “will this file load in my agent.” It does not answer which agent carries which skill, who may change it, and where the results go. That management problem grows with every agent you add.
In Sharkly, a Skill uses SKILL.md as its entry point, with YAML name and description followed by instructions, per the Skills docs. You can upload a SKILL.md, a .skill file, a zip, or a folder; import from a supported public URL; or import Skills that a Computer’s Runtime has already discovered. Imports become managed copies, so the docs say to review them before binding. Every Skill has one scope (Organization, Space, or Agent), fixed at creation, and edits are limited to the creator and Organization Owners or Admins. Sharkly Skills walks through each path.
Binding happens on the Agent, and the Agent is where you pick the Runtime. A Crew is “a reusable group of People and Agents coordinated by one leader Agent,” per the Crews docs, and each Agent member keeps its own configuration. So a Crew whose leader runs on Claude Code and whose reviewer runs on Codex can bind the same Space Skill, and each member’s results still return to the same Task. The Agents research, execute, test, and report. People decide which Skills carry team authority and accept the result.
You can keep skills in sync by hand with one folder and a symlink per repository, or use Sharkly to manage which Agents carry them as the team grows. For running the two agents side by side, Claude Code and Codex on one codebase covers the worktree side.
FAQ
Did the Agent Skills format change when it moved to the Agentic AI Foundation? No. The announcement transferred the name, logo, GitHub organization, domain, and standard. The spec at agentskills.io is the same file, and existing SKILL.md skills keep working.
Who maintains Agent Skills now? Engineers from Anthropic, Google, OpenAI, and other companies, acting as individuals, with David Soria Parra and Mahesh Murag as Lead Maintainers, per Anthropic’s post. Anthropic has proposed versioned releases and a formal proposal process; neither is shipped yet.
Which agents support Agent Skills? Anthropic says more than 70 platforms, naming ChatGPT, Cursor, GitHub Copilot, and VS Code. The client showcase on agentskills.io lists products including Claude Code, Codex, Gemini CLI, OpenCode, Goose, and OpenHands. Each product picks its own skill directories, so check its docs.
Do I need to join the foundation to write or contribute skills? No. Anthropic’s post says you can keep using or contributing to the standard without joining, and spec feedback goes through the project’s Discord.
Will a skill written for Claude Code work in Codex? If its frontmatter sticks to the six spec fields and it lives where Codex looks, yes in format terms. Claude Code extensions such as context: fork will not carry over, so keep them out of the shared copy. Moving skills is only part of switching agents; keeping context when switching between coding agents covers the rest.
