Agent Skills now belongs to the Linux Foundation. Check your skills against the spec before you share them

Anthropic is giving away the Agent Skills standard. On 22 October 2026 it announced that the specification, the name and logo, the GitHub organisation and the agentskills.io domain are moving to the Agentic AI Foundation, which sits under the Linux Foundation and also hosts the Model Context Protocol. Engineers from Anthropic, Google, OpenAI and others will maintain it as individuals, and Anthropic names David Soria Parra and Mahesh Murag as Lead Maintainers.

Nothing changes in your repo today. A SKILL.md file works the same way it did last week. What changes is who decides what a skill is allowed to contain, and that matters more than it sounds if you’ve been writing Claude Code skills with all the fields Claude Code offers.

What the announcement says, and what it doesn’t

According to Anthropic’s post, more than 70 agent platforms have integrated the standard since it was published in December 2025, including ChatGPT, Cursor, GitHub Copilot and VS Code. The post also puts the number of published skills at about 1 million, with nearly 280 million installs. Those are Anthropic’s figures, and the post doesn’t say how they’re counted.

The roadmap is a proposal, with no dates: versioned releases, a formal proposal process, and security guidance for people who write and install skills. The post doesn’t cover voting rules, membership terms or release timelines. Joining the foundation isn’t required to use or contribute to the standard.

The security guidance is the part to watch. A skill is a folder of instructions plus optional scripts that an agent loads on demand, so installing one is closer to adding a dependency than adding a note. Tokenise has covered vetting Claude Code mods before install , and the same instincts apply to any skill you didn’t write.

The portability gap

The spec is small. A skill is a directory with a SKILL.md file. The YAML frontmatter has two required fields, name and description, and four optional ones: license, compatibility, metadata and allowed-tools (marked experimental). The name is capped at 64 characters, limited to lowercase letters, digits and hyphens, and has to match the directory name. The description is capped at 1,024 characters.

Claude Code is more generous. Its docs list fields the standard doesn’t have: disable-model-invocation, context, agent, model, effort, hooks, paths, when_to_use and more. Claude Code silently ignores keys it doesn’t recognise, so nothing warns you when a field is a Claude Code extension. The docs also say that outside Claude Code only the six standard fields are allowed. Any other key is a hard error on claude.ai uploads, in the Skills API and in package_skill.py.

So a skill that works perfectly in your terminal can fail the moment someone packages it. Claude Code also lets name differ from the directory name, which the spec forbids. Neither quirk is a bug. They’re the cost of an extended dialect, and it helps to know which side of the line each of your skills is on.

Check them with the reference validator

The standard ships a reference library, skills-ref, in the agentskills/agentskills repository. Its README says it’s for demonstration only and not meant for production, so treat it as a linter and not as a gate you bet a release on. It’s Apache-2.0, depends on click and strictyaml, and the code that runs is short: it reads SKILL.md, parses the frontmatter and compares it with the rules above. It doesn’t touch the network. The last commit was on 9 August 2026. Read validator.py before you install it, which takes five minutes.

Install it from a checkout, not from a package index:

git clone --depth 1 https://github.com/agentskills/agentskills
python3 -m venv .venv
.venv/bin/pip install -e agentskills/skills-ref

The CLI has three commands: validate, read-properties (prints the parsed fields as JSON) and to-prompt (prints the <available_skills> XML an agent would see). Here are three project skills: one that sticks to the standard, one that uses Claude Code extensions, and one with a badly formed name.

.claude/skills/pr-summary/SKILL.md      license, compatibility, metadata
.claude/skills/release-notes/SKILL.md   disable-model-invocation, context: fork, allowed-tools
.claude/skills/Review_Diff/SKILL.md     name: Review_Diff

Run the validator over each directory and it prints:

Valid skill: .claude/skills/pr-summary
Validation failed for .claude/skills/release-notes:
  - Unexpected fields in frontmatter: context, disable-model-invocation. Only ['allowed-tools', 'compatibility', 'description', 'license', 'metadata', 'name'] are allowed.
Validation failed for .claude/skills/Review_Diff:
  - Skill name 'Review_Diff' must be lowercase
  - Skill name 'Review_Diff' contains invalid characters. Only letters, digits, and hyphens are allowed.

Note that allowed-tools: Bash(git log:*) Read passed. It’s one of the six, with the space-separated format the spec uses. disable-model-invocation and context are the ones that failed, and they’re exactly the fields that make a Claude Code skill useful for a destructive or expensive task.

Make it a CI step

Because skills-ref validate exits non-zero on failure, a loop is enough:

#!/usr/bin/env bash
# Fail if any project skill breaks the Agent Skills spec.
status=0
for dir in .claude/skills/*/; do
  skills-ref validate "$dir" || status=1
done
exit $status

Run on the three skills above, it prints the output shown earlier and exits with status 1. That’s the wrong result if you consider Claude Code extensions fine, so decide the policy before you wire it in.

Two policies work. If skills only ever run in Claude Code, skip the extension check and keep only the name and description rules, which are the ones every client enforces. If skills are shared across tools or uploaded to claude.ai, run the validator as shown and move the extensions out. The cleanest split is a standard-compliant skill that carries the instructions, plus a Claude Code wrapper for anything that needs context: fork or disable-model-invocation.

What to do with the context cost

The spec’s progressive-disclosure numbers are worth checking against your own skills. The spec says name and description cost about 100 tokens per skill at startup, the SKILL.md body should stay under 5,000 tokens and 500 lines, and long reference material belongs in separate files one level deep. Claude Code’s own docs add a second limit: the description plus when_to_use is truncated at 1,536 characters in the skill listing.

A skill with a 900-character description fits the spec and still pays for itself on every session start. Descriptions that say what the skill does and when to use it, in a sentence or two, are cheaper and easier for the agent to match. For a worked example of a skill that’s tested properly, see running skill regressions in CI and a skill that writes pull request descriptions .

Limits of the check

The validator checks structure, not behaviour. A skill can pass and still be vague, stale or unsafe, and the check says nothing about scripts in scripts/. It also can’t tell you how Cursor, Copilot or ChatGPT treat a field the spec marks experimental, such as allowed-tools. Support for it varies by implementation, according to the spec itself.

And the standard will move. A formal proposal process and versioned releases mean the six-field list can grow, and a check pinned to today’s skills-ref will start flagging fields that become legal. Pin the checkout to a commit and update it on purpose.

Try it this week

Run skills-ref validate over every directory in .claude/skills/ and ~/.claude/skills/. For each failure, decide whether it’s a Claude Code extension you want to keep or a name you should have written in lowercase, and fix the second kind now.