On 22 October 2026, Anthropic donated Agent Skills, the format used to give an AI agent instructions and procedures, to the Agentic AI Foundation, under the Linux Foundation. For a development team, the news has two sides, and both are worth reading.
The idea this insight argues: if the format is open, your team's method (how it specifies, how it reviews, what it checks) can be written once and taken to any agent. But what others write comes in through the same door: a skill from a public registry is a dependency, and it gets installed with the same criteria as an npm or PyPI package.
What has changed
Until now, Agent Skills was a format created by Anthropic that other tools had adopted. Since 22 October, engineers from Anthropic, Google, OpenAI and other companies maintain it as individuals, within the Agentic AI Foundation, with a commitment to keep it "open, community-driven, and vendor-neutral". Three figures from the announcement, which come from Anthropic itself:
Risk The adoption figures come from Anthropic, an interested party. A tool having integrated the format does not guarantee it supports every part of it: check your tool's documentation.
What a skill is
A skill is a folder containing a SKILL.md file. That file holds some metadata (at minimum, a name and a description) and the instructions for a specific task. The folder can also include scripts, reference documentation and templates. At startup the agent reads only the name and description of each skill, and loads the full instructions when a task matches it.
The specification explains it like this: skills package procedural knowledge and team- and company-specific context into "portable, version-controlled folders". And it sums it up in one line: build a skill once and use it across any skills-compatible agent.
What your team gains
What really sets apart a team that works well with agents is not the tool but what it has written down: how a spec is drafted, which acceptance criteria it carries, what gets checked before a merge, which architecture decisions the agent cannot guess. It is the point we made about Spec-Driven Development (SDD), building software from a written specification, in SDD templates are free now: anyone can give you the template; the method belongs to the team.
With an open format, that method stops being tied to one vendor. A skill that explains how your team specifies in SDD works just as well if part of the team uses another agent tomorrow. The same goes for architecture decisions and for the team's shared instructions: if they live as skills in the repository, they are versioned, reviewed and kept when the tool changes. At onext we don't lock you into a single vendor, and this is one of the reasons the method should live in the team's repository.
What your team has to control
The other side is the same fact seen from outside. A format that works on more than 70 platforms and has public registries with thousands of skills is also a supply chain. A third-party skill can carry instructions the agent will follow and scripts it will run with your permissions. The first analyses of those registries give reasons to look before installing:
Risk Snyk sells security tools for this problem: this is vendor research. The academic study is a preprint without peer review. Both analyse public, community registries, which do not look like an internal repository with review.
The conclusion is not that skills are dangerous, but that they are code. Snyk puts it this way: skills are a software supply chain and need the same security rigour we apply to npm, PyPI and container registries. The Cloud Security Alliance, in a May 2026 briefing for security leaders, goes further: agent context files must be treated as untrusted third-party code, and it recommends content hash verification before loading skills into production. The standard's own roadmap includes security guidance for people who write and install skills.
It is the same discipline we asked for with the dependencies an assistant suggests and with the MCP servers nobody governs: knowing who publishes what runs, and not letting the version change on its own.
Two kinds of skill, two rules
The table is our proposal for separating what is written in-house from what is brought in:
| Team skill | Third-party skill | |
|---|---|---|
| What it is | The written method: how work is specified, reviewed and checked | A dependency: instructions and, sometimes, code the agent runs |
| Where it lives | In the repository, next to the code | In the repository, with the version pinned, never downloaded on the fly |
| Who approves it | The team, by pull request | The team, by pull request, after reading it in full |
| What gets checked | That the agent behaves as it says (the agent's evals) | Origin, content, scripts, permissions requested and hash |
| If you switch agents | It travels with the team | It is reviewed again if the version changes |
onext's own analysis based on Snyk (2026), the Cloud Security Alliance (2026) and the Agent Skills specification
Before installing a skill from outside
Five steps we propose for any skill the team did not write:
- Read it in full, including scripts and reference files, not just the description.
- Check who publishes it, and be wary of skills that imitate a well-known brand's name.
- Pin the version or the content hash, so it does not change on its own at the next install.
- Bring it in through a pull request, like any dependency, with someone who signs off.
- Give the agent only the permissions the skill needs: if it has no reason to reach the internet or write outside the project, it should not be able to.
None of the five steps is new. What is new is applying them to something that looks like text. In many teams, changing the agent's code goes through review, but changing a skill does not, because "it's only instructions". A skill changes what the agent does as much as code does, which is why its changes should also trigger the evals on every pull request. And an agent that follows its instructions well does not guarantee a secure result, as we explain in agent code passes the tests and is not secure.
The skills your team writes are its method and travel with it. The ones it brings in are dependencies and get reviewed before they come in. Both live in the repository and go through the same door as the code.
Where to start
If your team already uses skills or shared rules with its agent, take an inventory: which ones the team wrote, which came from outside and which live outside the repository. The first are the method and deserve review like code; the second, the review of a dependency; the third should move into the repository. For a team skill to say something checkable, the same applies as for a spec: criteria that can be verified, as we explain in your spec is already an eval.
If you want to review it with someone from outside, the diagnostic is free, and if the diagnostic shows no difference, there is no Quick-start. How we work on a development team's method is at AI-Accelerated Development.
Frequently asked questions
What is Agent Skills?
It is an open format for giving an AI agent specific knowledge and procedures. A skill is a folder containing a SKILL.md file, which holds metadata (at minimum, a name and a description) and instructions, and can include scripts, references and templates. Anthropic created it and, on 22 October 2026, donated it to the Agentic AI Foundation, under the Linux Foundation.
Which tools support skills?
According to Anthropic, more than 70 agent platforms have integrated them, including ChatGPT, Cursor, GitHub Copilot and VS Code. The specification puts it this way: build a skill once and use it across any skills-compatible agent. Before relying on it, check your tool's documentation for which parts of the format it supports.
What does a development team gain by writing its method as skills?
How it specifies, how it reviews and what it checks get written down once, versioned in the repository and reviewed like the rest of the code. And that method is not lost if the team switches agents or uses several at once, because the format is the same.
Are third-party skills dangerous?
They are instructions the agent follows and, sometimes, code it runs, so they carry the risks of any dependency. Snyk analysed 3,984 skills from two public registries and found that 13.4% had at least one critical security issue and 76 were malicious. An academic study of 98,380 skills confirmed 157 malicious ones. That does not mean you should not use them: it means you review them before installing them.
How do you install a third-party skill safely?
Our proposal: read it in full before installing it, scripts included; check who publishes it; pin the version or the content hash so it does not change on its own; bring it into the repository through a pull request; and give the agent only the permissions the skill needs.
Where should the team's skills live?
In the repository, next to the code, reviewed by pull request like any change. A skill changes the agent's behaviour just as code does, so its changes should also trigger the agent's evals. Skills that live in a shared document outside the repository are reviewed by nobody.
Sources
- Anthropic, "Donating Agent Skills to the Agentic AI Foundation", 22 October 2026.
- Agent Skills, "Agent Skills Overview" and specification (undated; accessed 28 October 2026).
- Luca Beurer-Kellner, Aleksei Kudrinskii, Marco Milanta, Kristian Bonde Nielsen, Hemang Sarkar and Liran Tal (Snyk), ToxicSkills study of the agent skills supply chain, 5 February 2026 (vendor research).
- Yi Liu, Zhihao Chen, Yanjun Zhang, Gelei Deng, Yuekang Li, Jianting Ning and Leo Yu Zhang, ""Do Not Mention This to the User": Detecting and Understanding Malicious Agent Skills in the Wild", arXiv:2602.06547, version 4 of 10 June 2026 (preprint).
- Cloud Security Alliance (AI Safety Initiative), "CISO Briefing: Agent Context Poisoning: SKILL.md and the New AI Supply Chain Attack Surface", 6 May 2026.
- The table of the two kinds of skill and the five steps are onext's own analysis.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →