Skills: The Quiet Standard Every AI Coding Tool Agreed On
Here is a thing that almost never happens in this industry: a bunch of competing companies, all racing each other, all with their own opinions, quietly agreed on the same file format. No committee. No standards body sending out a 200-page PDF. Just a folder with a Markdown file in it, and one by one, the tools started reading it.
That file is called SKILL.md, and the folder it lives in is a Skill. By early 2026, Claude, Cursor, IBM Bob, OpenAI Codex, Gemini CLI, GitHub Copilot, JetBrains Junie, and more than a dozen others all read it. Same shape, same rules, mostly the same behaviour. If you write a Skill for one of them, it tends to just work in the others.
I want to walk through what a Skill actually is, the one design idea that makes the whole thing tick, and then the part nobody explains well: where Skills earn their keep, with real scenarios. No copied docs, no hand-waving. Let me show you the moving parts.
A Skill is smaller than you think
Strip away the hype and a Skill is a folder. Inside it, one required file, SKILL.md. At the top of that file, a few lines of YAML with exactly two things that matter: a name and a description. Below that, plain instructions written for the agent. That is the whole minimum.
That description line is doing more work than it looks. It is not decoration. It is the trigger. The agent reads every Skill’s description up front and uses it to decide, later, whether this Skill is relevant to what you just asked. A vague description means the Skill never fires when it should. A sharp one (“use when the user mentions PDFs, forms, or extraction”) means it fires at exactly the right moment. Writing that one line well is most of the skill of writing a Skill.
The one idea that makes it work: progressive disclosure
Here is the problem Skills are quietly solving. You might have fifty Skills installed. If the agent loaded all fifty into its head every time you typed something, your context window would be full before you asked your first question. Useless.
So Skills don’t load all at once. They load in stages, only as far as the task needs. This is the whole trick, and it is called progressive disclosure. Watch it happen:
per skill
tokens
unlimited
The reason this matters becomes obvious the moment you put real numbers on it. The cost of knowing a Skill exists is tiny. The cost of actually using it only shows up when you use it. And the bundled files, the reference docs and scripts, cost nothing at all until the moment they are opened.
There is a second, sneakier win hiding in level 3. When a Skill bundles a script, say validate_form.py, the agent does not read the code into its head and reason about it. It just runs it and reads the output. “Validation passed.” That is it. The script’s hundred lines never touch the context window. For anything that needs to be exact and repeatable, a regex, a calculation, a file transform, this is both cheaper and far more reliable than asking the model to generate the equivalent on the fly.
So a Skill quietly hands the agent the right tool for each kind of work: prose instructions for judgement, reference files for facts, and scripts for the things that must be deterministic.
What is actually sitting in context right now
Picture the agent’s context window as a row of slots. With ten Skills installed, here is what is loaded before you have asked anything, and what changes the instant you ask about a PDF:
The part that surprised me: it travels between tools
This is the bit that made me sit up. Skills are not a Claude feature that other tools cloned badly. They are close enough to a shared format that a Skill written for one tool is read by the next.
Cursor is the clearest example. It looks for Skills in its own folders, of course, but it also reads .claude/skills/, .codex/skills/, and .agents/skills/. So a Skill you wrote for Claude Code, sitting in .claude/skills/, is picked up by Cursor with no changes. Write once, and a whole row of tools can use it.
By early 2026 the list of tools that understand Skills had grown past sixteen. Here is the rough shape of who is in:
Now, “mostly compatible” is not “identical,” and the differences are worth knowing. Same idea, slightly different dialects:
| Tool | Where Skills live | Worth knowing |
|---|---|---|
| Claude Code | ~/.claude/skills/ (personal), .claude/skills/ (project) | Filesystem based, no upload. Custom Skills only. |
| claude.ai | Uploaded as a zip in Settings | Per-user, does not sync to the API or to Claude Code. Each surface is separate. |
| Cursor | .cursor/skills/, ~/.cursor/skills/, plus .claude/ & .codex/ | Reads other tools' folders too. Extra frontmatter: paths, disable-model-invocation. |
| IBM Bob | .bob/skills/ (project), ~/.bob/skills/ (global) | Asks approval before activating a Skill by default. Available in Advanced mode. |
Skills are not Rules. Don’t mix them up.
If you use Cursor you have probably written Rules, the always-on instructions in .cursor/rules/. When Skills arrived, a lot of people asked whether Rules were now dead. They are not. They do different jobs, and the difference is clean once you see it.
Rules always on
- Loaded into every conversation, every time.
- Best for hard constraints: "always use tabs," "never call the legacy API."
- Declarative. They state how things must be.
- Cost context on every single turn, used or not.
Skills on demand
- Loaded only when the task matches the description.
- Best for procedures: "here is how to cut a release," "here is our migration runbook."
- Procedural. They teach a multi-step how-to.
- Cost almost nothing until the moment they fire.
The rule of thumb I use: if it is a standard you never want broken, it is a Rule. If it is a process you follow when a certain kind of task shows up, it is a Skill. Coding style, error-handling conventions, banned dependencies, those are Rules. Cutting a release, onboarding a new service, filling a compliance form, those are Skills.
Where Skills actually earn their keep
Concepts are easy to nod along to. Let me put four real scenarios on the table, the kind you actually hit, and show what a Skill changes in each.
Notice the through-line. Skills are not for one-off requests, you would just type those. They are for the repeated, shaped, slightly-fiddly work: the procedure you do every sprint, the framework the model keeps fumbling, the chore that needs to be exact. That is the sweet spot.
The catch, because there always is one
A Skill can bundle scripts, and the agent will run them. That is the power and the danger in the same sentence. A Skill from an untrusted source is, functionally, code you are about to execute with whatever access your agent has. The official guidance across these tools is blunt about it: treat installing a Skill like installing software. Audit the SKILL.md, audit the scripts, watch especially for anything that reaches out to an external URL, because fetched content can carry instructions of its own.
This is not paranoia, it is the same rule you already apply to npm packages and browser extensions. A Skill is convenient precisely because it can act. Convenience that can act is convenience you have to trust.
The quiet lesson
What I keep coming back to is how small the winning design was. Not a grand framework. A folder, a Markdown file, two required lines, and one good idea about loading things only when you need them. That is it. And because it was small and obvious and easy to read, everyone could agree on it, and now the same Skill runs across Claude, Cursor, Bob, Codex, and the rest.
The next time you find yourself pasting the same multi-step instructions into an agent for the third time this week, that is the signal. That paragraph wants to be a Skill. Write the name, write the description that says when to use it, drop in the steps, and let progressive disclosure carry it from there, in whatever tool you happen to open tomorrow.