Skills: instructions in a folder, and why they spread faster than servers
Anthropic's Agent Skills are a directory with a markdown file in it. The model reads the description at startup and the rest only when it needs to. The format is small enough that it has already been copied, and small enough to be a supply chain problem.
What a skill is
A skill is a directory containing a file called SKILL.md. The file starts with YAML frontmatter that has two required fields, name and description, and the rest of the file is instructions written for the model. The directory can also hold other files, reference documents, forms, and scripts the model can execute. That is the whole specification. Anthropic announced the format on October 16 and says it works across Claude.ai, Claude Code, the Agent SDK and the developer platform. Simon Willison had reverse engineered it from the code interpreter environment about a week earlier.
The design principle is progressive disclosure, and Anthropic's engineering post lays out three levels. At startup only the name and description of each installed skill go into the system prompt, so the model knows what exists and roughly when to use it. When a task matches, the full SKILL.md is loaded. Files bundled alongside it are read only if the instructions point to them and the model decides it needs them. Willison's estimate is that each skill costs a few dozen tokens until it is triggered, which is why you can install many of them without paying for any of them most of the time.
Why it is different from a tool protocol
The Model Context Protocol, released in November 2024, is a full specification with hosts, clients, servers, resources and three transports. It solves the problem of connecting a model to external systems, and it does that well. What it does not do is teach the model how to do a job. Willison's argument, which we find persuasive, is that a lot of the value people were trying to get from MCP servers was really documentation, and that shipping documentation as a running server with tool schemas is an expensive way to deliver a text file. He notes that MCP setups can consume tens of thousands of context tokens before any work starts.
A skill delivers the documentation as a text file. Anthropic's post is careful to say the two are complementary. Skills teach workflows that may involve external tools, and MCP is how those tools get connected. The PDF skill example in the post is a good illustration. It bundles a Python script that extracts form fields from a PDF, and the model runs the script rather than reading the PDF into context. The skill is instructions plus code, and it needs a runtime with a filesystem and a code execution tool to be useful at all. Without those it is a README.
Why it spread
A format that is a folder with a markdown file in it has no barrier to adoption. You do not need a server, a schema, an SDK or a registry. You write instructions the way you would write them for a new colleague and drop the folder in a directory. Willison's example is a hypothetical data journalism skill with sub-documents on fetching census data, loading it into a database and visualising it, which is exactly the kind of tacit process knowledge that never fits into a tool definition.
The clearest evidence for the format's momentum came two months after the announcement. Willison documented in December that OpenAI's Codex CLI had merged a pull request adding experimental support for skills, that any folder under a skills directory is treated as a skill, and that the layout mirrors Anthropic's closely enough that he could take a skill he wrote for one and use it in the other. Both companies publish their own skills in public GitHub repositories with similar structure. Nobody negotiated a standard. The spec was light enough to copy.
The supply chain problem
The same properties that make skills spread make them dangerous. A skill is a set of instructions the model will follow, plus code the model will run, and installing one is a matter of copying a directory. Anthropic's post says to install skills only from trusted sources, to audit less trusted ones thoroughly, to read every bundled file, and to watch for dependencies and external network connections. That is the same advice given for npm packages and browser extensions, and the track record of that advice is not encouraging.
Willison's framing is that skills depend entirely on filesystem access and an execution environment, so the safety of the whole arrangement rests on the sandbox. A prompt injection that gets a model to load a malicious skill, or a skill in a public repository that includes a script doing something its SKILL.md does not describe, is the obvious attack. The progressive disclosure design makes it worse in one specific way. Because only the description is visible at startup, a reviewer looking at what is installed sees a one line summary written by the person who may be the attacker.
What we would do with this
For our own work the immediate use is capturing the procedures that currently live in people's heads and in scattered notes. How we run an eval, how we format a results table, which checks we do before a release. Those are skills in the literal sense and they are cheap to write. We would start there rather than with anything clever.
The thing we want someone to build is the equivalent of a lockfile and a signature for a skill directory, so that what runs is what was reviewed. Until that exists, the sensible policy is that skills come from your own repository or from a vendor you already trust with code execution, and nothing else gets installed no matter how good the description sounds. The description is the part the attacker writes.
Sources
From the foundation