The Cancer of Skills
Skills promise expertise for AI agents, but they remain fragile, insecure prompts that are hard to test, and they are impoverishing the people who are learning to use AI.
In less than a year, skills have become the way the generative AI industry tells itself it has solved the problem of agent specialization, and the speed at which the concept has spread should already make us suspicious. They began as an Anthropic convention for Claude, were then published as an open specification, and were adopted by most agentic coding tools. Today skills are presented as packages of expertise that a model acquires and uses when needed, in a vocabulary that evokes learning, modularity and software reuse.
The thesis of this article is that behind that vocabulary lies a mechanism much poorer than it is made to seem, and that the gap between what skills are and what is said about them is causing real damage on three levels: the reliability of systems, security and, perhaps the most serious, the education of the people who use and design AI. The comparison with uncontrolled growth is deliberate, because the problem lies less in any single skill than in the proliferation of a habit that feeds itself, spreads by imitation and takes up the space where real competence should grow.
To be useful, a critique has to be precise. So we will start with what is actually inside a skill, then examine the symptoms one by one, deal with the most serious objections and close with what, in my view, we really need.
Anatomy of a skill
According to the specification published on agentskills.io, a skill is a folder whose only required element is a SKILL.md file, made up of a YAML frontmatter and a Markdown body. Optional folders can sit alongside it for executable scripts, reference documentation and assets. The frontmatter requires only two fields: a name of at most 64 characters, and a description of at most 1024 characters that should say what the skill does and when to use it. The other fields, including the allowed-tools field that pre-approves the tools that can be used, are optional and partly declared experimental, with support that varies from one implementation to another.
The most telling detail concerns the body of the file. The specification states explicitly that there are no format restrictions and that you can write anything that helps the agent carry out the task. Consistently, the reference validation tool checks that the frontmatter is well formed and that the name follows the conventions, and has nothing to say about the content, because the content is free text meant for a language model.
The execution mechanism is what the specification calls progressive disclosure, and it works on three levels. At startup, the name and description of every available skill are loaded into the context, about a hundred tokens each. When the model judges a skill relevant, it loads the whole body, which is recommended to stay under five thousand tokens. Finally, auxiliary files are read only if and when the instructions call for them. The Microsoft Agent Framework documentation describes the same scheme in even more explicit terms, with the descriptions injected into the system prompt and a tool that returns the body of the skill to the model that invokes it. It candidly admits that the instructions are injected into the context and may influence the agent’s behavior.
Stripped to the bone, then, a skill is a fragment of prompt with a label, an index the model consults to decide whether to read it and, optionally, code the model can decide to run. Everything that follows comes from this description, which is worth keeping in mind every time you hear about skills the agent has “acquired.”
First symptom: a prompt disguised as an abstraction
Software engineering built its most successful abstractions (the function, the module, the interface, the package) around a precise idea: whoever uses a component can rely on what the component declares it does, without knowing what is inside. An abstraction is worth as much as its behavior is determined by its declaration, and this is exactly the property that lets us compose it, replace it and reason about it.
The skill borrows the whole surface of this vocabulary, with its folders, its metadata, its license and version fields, its validator and its installation ecosystem, without having the property that justifies it. Its behavior depends on how a probabilistic model interprets a natural language text in a context that also contains everything else: the rest of the conversation, the other loaded skills, the platform’s system prompt and any tool outputs. None of these variables is under the control of the person who writes the skill.
The result is an object that looks like a software component and has the semantics of a piece of advice. This would be a minor problem if it were stated clearly, but the entire communication apparatus around skills talks about capabilities, competencies and modules, and leads those who adopt them to treat them with the trust reserved for a library. They should be treated with the caution reserved for a recommendation written by someone else and read by a colleague whose judgment you don’t know well.
Second symptom: routing left to chance
The weakest point in the whole mechanism is the moment when the model decides whether to load a skill. The model makes that decision itself, based on a description of a few lines, with no explicit rule to govern it. The specification recommends including keywords in the description that help the agent recognize relevant tasks. That amounts to admitting that routing works by lexical and semantic similarity, which is the same approximate way a poorly configured search engine works.
The available data confirms that the problem is far from theoretical. In January 2026 the Next.js team at Vercel published the results of a series of evaluations on Next.js 16 APIs that were absent from the models’ training data. They compared a documentation skill with a compressed index of about 8 KB placed directly in AGENTS.md, the context file that is always present. In 56% of cases the skill was never invoked, and its mere presence produced the same success rate as having no documentation at all, with a drop on the tests (58% versus 63%) that the authors attribute to the noise introduced by a tool that is available but unused.
| Configuration | Success rate | Difference from baseline |
|---|---|---|
| No documentation | 53% | — |
| Skill, default behavior | 53% | +0 points |
| Skill with explicit invocation instructions | 79% | +26 points |
| Documentation index in AGENTS.md | 100% | +47 points |
When an instruction requiring the use of the skill was added to AGENTS.md, the invocation rate rose above 95% and the success rate to 79%. But the same study documents that different wordings of the same instruction produced very different behaviors, to the point that the authors call the approach fragile for production use. The paradox is worth pausing on: to make a skill work, it took an always-present prompt telling the model to use it, and the best solution was to eliminate the decision altogether.
In fairness, this is a single domain, measured with the models available in early 2026, and Vercel itself acknowledges a role for skills in vertical workflows explicitly triggered by the user. But that is exactly the point. A skill that works reliably only when someone invokes it by hand serves the function of a command, and a command does not need a apparatus of metadata and automatic discovery to exist.
On top of all this comes the absence of any contract. A function declares its inputs and outputs, an API has a schema, a tool has at least a typed signature. A skill declares no preconditions, effects or guarantees, and two skills with overlapping descriptions compete for the model’s attention with no precedence criterion other than the statistical mood of the moment.
Third symptom: versions that version nothing
The specification includes a metadata field where the official examples put author and version, and the ecosystem quickly built registries, install commands and public repositories around it, giving the impression that a skill has a life cycle comparable to that of a software dependency. The impression is misleading, because the version number captures only the text, while the actual behavior is the product of that text with a model, a platform and a context that change independently.
The same skill at version 1.0 behaves differently on Claude, Codex, Gemini CLI or Cursor. It also behaves differently on the same client when the vendor updates the underlying model, changes its own system prompt or changes the way it presents the list of available skills. The specification itself acknowledges that support for some fields varies across implementations, and the reference documentation advises testing every skill on multiple clients. That means admitting that the portability promised by the open standard concerns the file format, while what the file produces remains tied to the model that reads it.
From this follows a testability problem that no current tool solves satisfactorily. A unit test is not enough to verify a skill. You need repeated evaluations on samples of representative tasks, with separate measures for correct activation, for rejection of neighboring but wrong skills, and for execution quality, all repeated at every model update. It is serious work, which mature organizations do for their production prompts, but which the skills published in public repositories rarely account for. Nothing signals its absence, because the official validator only checks the frontmatter.
The practical result is silent regression as a normal operating condition. A company that builds its processes on a set of skills discovers that something has stopped working only when a wrong output reaches downstream. There is no changelog to consult, no diff to explain the difference, and no way to pin the version of the component that actually changed, which is the model.
Fourth symptom: a supply chain built on implicit trust
A skill can carry two kinds of payload, natural-language instructions and executable code, and the agent treats both with far more trust than it would give to ordinary input, because it receives them as part of its own configuration. This makes a skill a more insidious attack vector than a compromised npm package: classic supply chain techniques are joined by prompt injection, and the latter escapes static analysis tools by construction, since they cannot read the intent of a paragraph of prose.
The first large-scale analysis, Agent Skills in the Wild by Liu and colleagues, examined 31,132 skills collected in December 2025 from two public marketplaces. 26.1% had at least one potentially dangerous pattern and 5.2% had high-severity patterns consistent with malicious intent, while skills that included scripts were 2.12 times more likely to be vulnerable than those made of instructions alone. The authors themselves point out that many of the cases reflect negligence more than malice, and that the data captures an ecosystem in its first two months of life. They also note, however, that common SAST tools, tested on a subset, caught none of the injection patterns present in the instructions.
Later research points in the same direction. The ToxicSkills report from Snyk, covering 3,984 skills, found critical-level issues in 13.4% of them and 76 confirmed malicious payloads. 91% of those combined malicious code with prompt injection, and some of the malicious skills were still installable at the time of publication. For completeness, I should also mention the work of Holzbauer and colleagues. Across more than 238,000 skills, they drastically scale down the percentages produced by automated scanners, bringing the share of suspicious skills below 1% once the repository context is taken into account. But they, too, document a new vector: the hijacking of skills hosted on abandoned GitHub repositories.
The structural point does not depend on the exact percentage. The problem stems from what the first study calls the consent gap, that is, the distance between what the user approves by installing a skill and what the skill actually does. It is made worse by the fact that the activation mechanism is implicit, and that the field meant to limit which tools can be used is, by the specification’s own admission, experimental and unevenly supported. We have effectively rebuilt the browser extension ecosystem of the early years, with less sandboxing, no code signing, no binding permission model, and on top of that a semantic attack surface that nobody yet knows how to inspect reliably.
Fifth symptom: the atrophy of skill
This is the damage I consider the most serious, because sooner or later reliability and security problems will be addressed with technical tools, whereas what is lost in terms of training is hard to recover. To work well with a language model, you need to understand a few things that are not learned by installing packages: everything the model knows about a task passes through the context, the order and wording of information matter, every instruction competes with the others for the model’s attention, and an output must be checked against external criteria, not against your own expectations. These ideas are simple to state and hard to internalize, and they are internalized only by writing, getting things wrong, measuring and correcting.
The skill offers a shortcut that skips exactly this step. Anyone approaching the professional use of AI today finds catalogs with tens of thousands of ready-made procedures. They get used to looking for the right skill instead of asking what the model is missing to do the task, and they credit successes to the skill and failures to the model, without ever acquiring the tools to tell the two apart. The very language used to present skills, which talks about abilities the agent acquires, reinforces a wrong mental model, one in which the system learns something, when in reality no weight changes and all that happens is that a file gets read.
There is also a homogenizing effect, less obvious but just as real. When thousands of users install the same skills to write documents, design interfaces or review code, the outputs converge on the stylistic and methodological choices of the few people who wrote those skills, often without stating their assumptions and without the users noticing they have adopted them. The result is a monoculture of procedures that nobody has really chosen, because they arrived as defaults.
Finally, skills move knowledge out of people and into files that nobody rereads. In an organization, the knowledge of how to do something stops living in the heads of those who do it and crystallizes in a markdown file written by someone months earlier, perhaps for a different model. When that markdown stops working, no one is left who can understand why, because no one ever had to understand how it worked.
The Predictable Objections
A critique that does not face the strongest objections is easy to dismantle, so it is worth examining them one by one and acknowledging what they get right.
The first objection says that progressive disclosure solves a real problem: you can’t keep the instructions for dozens of different tasks in context without degrading performance. That’s true, and the context window problem does exist. But Vercel’s data shows that a compressed index that is always present, and that points to files to be read on demand, gets better results precisely because it removes the activation decision. So the useful part of progressive disclosure, the deferred loading of content, can be had without the fragile part, which is leaving the routing to the model.
The second objection points out that a skill is at least a readable file, more transparent than a fine-tuning or a hidden system prompt. This is also true, and I consider it the format’s main merit. But a file being readable doesn’t guarantee that anyone reads it, and the studies I cited show that many vulnerable skills piled up downloads and stars before they were discovered. Potential transparency is worth something only when it comes with a culture of review, and the current ecosystem discourages that culture, because it is built on quick installation.
The third objection reminds us that skills can include deterministic code, and that in that case the reliability is the reliability of the code. Correct, but the choice of when to run that code, with which arguments and how to interpret its output is still left to the model, and that same code is the component tied to the highest security risk. A well-written script inside a skill remains a well-written script, one that could have been exposed as a tool with a typed signature and explicit permissions.
The fourth objection is the most serious one. It says that models will get better, that activation will become reliable and that many of the problems I describe are temporary. Maybe. Some of the numbers reported here refer to models and to an ecosystem from months ago. Still, a more capable model follows instructions more reliably in general, malicious ones included, and nothing in the improvement of models introduces contracts, binding permissions or versioning of behavior. As for the damage to learning, a system that works better without the user understanding why makes it worse, not better.
What we would need instead
Rejecting the format outright would be just as lazy as adopting it without thinking, and a few concrete suggestions can limit the damage I’ve described.
The first is to call things by their name. A skill should be treated, documented and reviewed like a production prompt, with the same rigor and the same distrust. Anyone who presents it as a competence of the agent contributes to a confusion that has real costs.
The second concerns activation. When an instruction must always be followed, its place is the permanent context, possibly as a compressed index that points to files to be read on demand. When a procedure is needed only in certain cases, it is better for the user or a deterministic orchestrator to invoke it explicitly, leaving the model the decision to load it only where a routing mistake costs little.
The third concerns code. Whatever can be deterministic should be pulled out of the instructions and exposed as a tool with a typed signature, minimal permissions and a sandbox. That way the reliable part of the system has a contract, and the probabilistic part is reduced to the bare minimum.
The fourth concerns evaluation. No skill should enter a professional workflow without a set of test cases that separately measure activation, missed activation and quality of execution, to be repeated at every model change. And no third-party skill should be installed without reading its instructions and scripts in full, exactly as you wouldn’t run a script found online with elevated privileges.
The fifth concerns education, and it’s the one I care about most. Anyone who teaches how to use AI should have students write their own instructions from scratch, measure them and break them, before showing them any catalog. Other people’s skills should be used as material to read and take apart, to understand what choices they contain and why they work or fail, and never as black boxes to install.
Conclusion
Skills are a fragment of prompt with a label, a loading mechanism left to the model’s judgment and, sometimes, code that the model may decide to run. As an organizational convention for people who already know how context engineering works, they can be handy, and it would be dishonest to deny it. The problem arises when this convention is presented as an engineering abstraction, distributed as an ecosystem of packages and adopted as a substitute for understanding. At that point it inherits the fragility of prompting, the attack surface of the supply chain and the opacity of third-party software, without any of the guarantees that make the latter bearable.
The comparison with a tumor is about exactly this dynamic of growth, in which a cell that is trivial in itself replicates without control, spreads by imitation and takes resources away from healthy tissue. Here the healthy tissue is the competence of people who design systems based on language models, and the culture of verification that those systems require. To cure it, we would only need to stop attributing to the format properties it doesn’t have, and go back to demanding, from those who build and those who learn, that they know exactly which text reaches the model, at what moment and with what consequences.
