Last week a lot of people told me the argument about skills was over. The models are so powerful now, they said, that you should stop writing skills and just get out of the way. Tell the model what you want and what your criteria for success are, and it will figure out how to do it. Stop doing the model's job for it.

I've been skeptical of skills since before that argument existed, so you'd think I'd welcome the news. I don't. Both camps are half right, and the two halves don't cancel out. They stack.

A skill is a process captured in natural language, in a markdown file, interpreted by a large language model. A model predicts the next token. It is nondeterministic. So if you write down a process — step one, step two, step three, do it exactly like this — you have written instructions for a machine that will follow them most of the time and will not follow them the same way twice. It is empowering and buggy at the same time, and the empowerment does not remove the bugginess.

The empowerment part is real. Millions of people who never learned to program can now capture a process and hand it to a machine. A nurse can write down how her clinic handles intake. A bookkeeper can write down how he closes a month. That is a genuine expansion of who gets to automate things, and it's the best thing about skills. But the file those people are writing is not a program. There is no compiler behind it, no type checker, no test that fails the build. When the interpreter drifts, nothing catches it. The drift is silent.

The research backs up the skepticism without settling it. A benchmark called SkillsBench evaluated skills across 84 tasks and 7,308 agent runs. Human-curated skills improved pass rates by an average of 16.2 percentage points. Self-generated skills — the model writing its own skills — provided essentially no benefit. And the gains varied enormously by domain: healthcare procedures jumped 51.9 points, while software engineering moved only 4.5 points, presumably because frontier models already know how software engineering works. On 16 of the 84 tasks, the skills made things worse. Models are better consumers of procedural knowledge than producers of it, and that means "the model can figure it out" is true in a narrower sense than its proponents intend.

Because the other camp has a point too. Instruction following has improved dramatically — Arize's instruction-following benchmark found that frontier models got roughly an order of magnitude better at following long, complex instruction sets in a single year. A skill with 2,000 words of instructions in it will probably be followed now, where two years ago it would have been partially ignored. Anthropic's own guidance for writing skills says to hand the model goals and constraints and let it navigate, rather than scripting exact commands — their bad example lists precise git commands, and their good example describes what a successful cherry-pick looks like. If your skill reads like a shell script written in prose, you wrote it wrong.

So which is it? The way out of the contradiction is to stop treating skills as one thing. A skill is a good place to put judgment. What good looks like in this domain. Which error actually matters and which one you can ignore. What to check before you ship. How this company's deployment is different from the default. That content is exactly what the model cannot get from its training data, and the SkillsBench numbers show it pays off — mostly in domains where the procedure is scarce knowledge, not in domains where the model already has it.

A skill is a bad place to put the process you want guaranteed. If the same steps must run the same way every time — billing, data migration, anything with money or patient records attached — the guarantee does not live in the markdown. It lives in the harness around the model: the script that runs identically every time, the test that fails the build, the schema that rejects a malformed payload, the tool call that either succeeds or throws. Those things are dumb and deterministic, and that is their value. The model has judgment; the harness has consequences. A skill can be politely ignored. A test cannot.

That is the deal skills were always operating under, and neither of the two camps wants to say it out loud. The skills-are-dead camp is right that scripting exact steps for a frontier model is wasted effort and usually a regression. The skills-are-the-future camp is right that curated procedural knowledge measurably helps, especially outside software engineering. But both camps are quiet about the part in between, which is where the actual work lives: judgment in the skill, consequence in the deterministic layer, and never the two swapped.

So no, the argument isn't over. It just got more specific. Write fewer skills. Put judgment in them, not choreography. And stop asking the model to do arithmetic it was never built to do — that complaint was right last year, and it is still right this year, no matter how good the model gets.