Why did every AI tool start shipping “skills” at the same time?

For about two years the unit of AI work was the prompt. You wrote a good one, it worked, you pasted it into a note, and three weeks later you could not find it — or you found it and could not remember which of the four versions was the one that worked.

Then, over a few months, almost every serious agent product started shipping the same thing under the same word: skills. Folders. With names. Versioned like code.

That kind of convergence is rarely fashion. It usually means several teams walked into the same wall.

The wall is not capability. It is transfer.

A prompt that works is a private result. It lives in one person's context, in one conversation, on one afternoon. It cannot be reviewed by a colleague, tested against a change, rolled back when it regresses, or handed to the new analyst who joined on Monday.

Every organisation that got past a successful demo hit the same three questions, in this order:

• Who else can run this? If the answer is “the person who wrote it,” you do not have a capability. You have a favour.
• What changed when it stopped working? Unanswerable without a version history.
• Does it still do what we said it does? Unanswerable without something to read.

None of those are model problems. All of them are packaging problems. A skill is the smallest package that answers all three.

What is actually in one

Strip away the branding and the shape is boringly consistent across products:

• A name, so it can be referred to.
• A description of when to use it — the part that decides whether an agent reaches for it at the right moment, and the part most people write last and worst.
• The procedure, in prose, in the order a competent person would do it.
• The supporting files: a checklist, a schema, a lookup table, a script.

Notice what is not in that list. No model name. No temperature. No vendor. A skill describes the work, not the machine — which is exactly why it outlives the machine.

The property that decides whether it was worth writing

There is one test, and it is not “does it work.” It is: can it move?

Move to another person. Move to another agent. Move to another vendor when the one you picked doubles its price or gets acquired. If your procedure is expressed as settings inside somebody's product, it moves nowhere, and every month you spend refining it deepens a hole you dug for yourself. If it is expressed as text you own, it is portable by construction.

This is the quiet reason the convergence happened. Vendors did not adopt skills to be generous. They adopted skills because customers who had been burned once refused to buy the unportable version again.

Where teams get it wrong

Writing the procedure they wish they had, not the one they run. The value is in the exceptions — the client type that needs a second signature, the reconciliation that always breaks on the last day of the quarter. Those are the parts nobody documents, and the parts that decide whether the output can be trusted.

Writing one enormous skill. If it covers four unrelated jobs, an agent cannot tell when to use it, and neither can a new hire. Skills should be about the size of a thing one person does in one sitting.

Treating the description as a label. It is a routing decision. “Handles invoices” tells nothing. “Use when an incoming invoice must be matched to a purchase order before payment approval, including partial deliveries” tells everything.

The strategic version

If skills are the unit, then the asset your organisation is building is not a model subscription. It is a library of written procedures that any capable system can execute — this year's, and the one that replaces it.

Which reframes the budget question. The spend that compounds is the one that produces text you own. Everything else is rent.