A better model will not fix a workflow you never wrote down

Every few months a better model arrives and teams wait for it, expecting the business result to improve. It rarely does, and the reason is simple: a better model gives a better answer to the same question. It does not change the question, and it does not change what happens to the answer afterwards.

If people are still typing ad-hoc prompts, still starting from scratch each time, still pasting results into a document that nobody reuses — the output improves a little and the business impact does not compound at all. Nothing about how the tool is used has changed.

What compounds is the part you write down.

The difference between a prompt and a skill

A prompt is something you typed once. A skill is a prompt that has been given a name, an owner, and a defined job, so anyone on the team can run it without re-explaining the task.

That is the whole distinction, and it is the one that separates a team where one person is good at AI from a team where everyone is.

One job per skill

The most common design failure: a skill with a vague, multi-purpose description. A "marketing skill" that researches, writes, and handles outreach will be mediocre at all three — because there is no single output you can judge it against, so nobody ever notices which part is weak.

The test: if the one-sentence purpose could describe two different jobs, it is too broad. Split it.

Splitting is not more work; it is less. Two skills with one job each are both easier to write, easier to fix, and easier to trust than one that does both badly.

Write it down as a card

For each skill worth keeping, one short page:

The last two rows are the ones people skip and the ones that make a skill safe to hand to a colleague. A skill with no stated weaknesses has not been used enough.

Only build one for work that recurs

A skill for a task you do once is wasted effort — you will spend longer designing it than doing the job. Build them for the weekly and the daily.

The corollary: when you find yourself explaining the same task to the tool for the third time, that is the signal. Not enthusiasm, not a planning exercise. The third repetition.

Test consistency, not just correctness

Before relying on a skill, run it on the same input two or three times, and on two or three different real inputs. You are looking for a different thing than accuracy: does it produce the same shape of output every time?

A skill that is right on average but structurally different each run cannot be built on, because the person downstream never knows what they are getting. That variance is invisible if you only ever run it once.

When you have more than a handful

Add one page listing them: name, what it is for, who owns it, when it was last changed. Without it people cannot find the right skill, so they write a new prompt, and you are back where you started with an extra folder.

The Belgian footnote on call transcripts

A common and genuinely useful skill extracts real customer language from sales or support calls. Two cautions before you build it:

Recording a conversation and then processing and storing it are separate questions, and the second brings the transcript squarely into data-protection scope. Decide who is told, what is kept, and for how long — before the first recording, not after fifty.

And when you do extract: keep the customer's words near-verbatim. The instinct is to polish quotes into marketing language, and that erases the exact specificity that made them worth collecting. "The last tool we tried needed a developer to set it up" is useful. "Ease of implementation was a concern" is not.