Agent Skills, the folder that teaches AI your procedures

You have heard about skills, or agent skills, and you cannot yet tell whether it is one more fashion. Here is the version that helps you decide: what it is, how it differs from what we call an agent, why it lowers a cost you already pay, and the one point where I ask you to let nothing through. By the end, you will know what to ask the team installing them.

What is a skill, concretely?

A folder. Nothing more: an instruction file in Markdown, plus the odd script or reference document beside it. The file opens with two required fields, a name and a description saying what the skill does and when to use it. The rest is procedure in plain language, the way you would write it for a new joiner. A CIO can tell me it is just Markdown, and on the file itself that is fair.

The difference is when it loads. The agent holds only the name and description of each skill, a few dozen words. When a request matches, it opens the folder and reads the whole procedure. That mechanism, not the file format, is what earns your attention: your know-how sits everywhere and weighs nothing until it is used.

How does it differ from MCP, a system prompt or an agent?

The three sit at different levels, and confusing them is expensive. The vendor's own line settles it: 'explaining how to do something is a skill; needing access to something is MCP'. So MCP wires the agent into your tools and gives it hands, the skill gives it your house method. Tools let an agent do things, skills let it do them well. What follows is a reading grid, not a standardized definition.

• A tool: a single function exposed to the model, with its input parameters.
• An MCP server: the connection layer exposing the tools and data of an outside system.
• A system prompt: a permanent instruction, valid for the whole conversation, so it is paid for on every call even when it is useless.
• A skill: a procedure loaded on demand, opening no access and weighing nothing until a request triggers it.
• An agent: the loop that decides, calls tools and corrects itself, with its own context and its own budget.

Why does it lower a real cost?

Because context is paid for on every call, used or not. An agent wired into ten tool servers loads every description before it has started, and often saturates its context before the first useful action. The official GitHub connector alone consumes tens of thousands of tokens, a public observation since late 2025. An untriggered skill costs a few dozen tokens.

Reworking part of those integrations into skills is a measurable optimization job: count the context tokens before, count them after, check that triggering stays accurate. I publish no average gain, for lack of a before and after measurement I could produce for you. The figures going round are isolated readings, never reproduced.

• The rule: the full procedure loads only when a request calls for it, never by default.
• The measurement: context tokens before and after, and correct triggering on representative requests.
• The limit: the Anthropic API caps at twenty skills per request today, and selection often degrades as the library grows.

What can go wrong?

Plenty, and this is the black spot. A skill is text the agent treats as a trusted instruction, plus sometimes scripts run with the user's own rights. A malicious instruction slipped into the file, including inside a comment nobody reads, becomes a persistent prompt injection. The specification provides no signature and no sandbox by default. The largest study published in early 2026 on public skill registries finds roughly one skill in four carrying at least one flaw, another puts it above one in three, and those bundling scripts are twice as often vulnerable.

• Where the files come from: a folder installed in one command from a public registry has been reviewed by nobody.
• What the folder holds: an instruction file alone is text, an attached script is code execution on the machine.
• The honest caveat: those figures cover public consumer registries, not a controlled enterprise deployment.
• What already exists: an experimental field limits which tools are reachable, and some implementations isolate execution. The specification does not guarantee it.

Who actually controls this format?

One vendor, and that is the caveat that matters. On adoption, the format published in December 2025 is already read by dozens of products, going by the showcase the vendor keeps, several of them direct competitors, and when direct competitors converge it is rarely a flash in the pan. On governance, the comparison with MCP runs the other way. MCP was handed to a neutral foundation in late 2025, the skills specification stays steered by its author: open by its license, not neutral by its governance. Portability stops at the format, since a skill that assumes a precise execution environment behaves differently elsewhere. The specification repository is less than nine months old. It is a building block I already assemble on assignment, not a norm settled for a decade.

How do you tell it is done right, without opening a file?

You do not need to open a single file. You need four questions, and the answers are usually enough to tell whether the team has a system or a pile of folders. None of these questions is mine: the vendor publishes the review grid for free, I only apply it.

• Provenance: a reviewed internal repository, or a public registry installed in one command.
• Who reviews them: the author of a skill cannot be its only reviewer, as for any other code.
• Are they pinned to a version: a silent update changes the instruction your agent follows.
• Are they evaluated before production: three to five representative requests per skill, replayed the way you measure an agent.

A tool gives the agent hands. A skill gives it the method. Without a review, it also gives it someone else's instructions.

So the real question is not whether to adopt skills, but which of your procedures deserve to become one, and who reviews them before an agent follows them. If your teams already install them and nobody keeps the list, a first conversation is enough to draw that list up, with no commitment: let's talk.