Skills beat prompts, and how to turn a workflow you repeat into one

Any workflow you run repeatedly ends up being explained repeatedly. Each explanation is a little different — you forget a step, you phrase a constraint less precisely, you leave out the caveat you learned three months ago.

The variation is invisible while it happens and entirely explains why the output quality wanders. You are not running the same process; you are running a fresh approximation of it.

A skill is that process written down once, in a form that gets loaded when it is relevant. The gain is not typing less. It is that the process stops being reconstructed from memory.

Repeated — you have done it at least three times. Below that you do not yet know what the stable parts are.

Multi-step — a single instruction does not need a document. The value is in sequence and in the steps people skip.

Non-obvious rules — the things you learned by getting them wrong. A workflow with no accumulated knowledge in it is just a list, and the agent could have produced the list.

That third criterion is the real test. The valuable part of a skill is rarely the happy path; it is the four warnings that come from experience.

The opening description determines whether the skill is ever loaded. It should name the situation in the words that will actually be present when it arises, including the ones you would type yourself.

Then the body:

• Steps in order, imperative, with the commands.
• Traps — what goes wrong, how to recognise it, what to do.
• Done — how to know the task is complete and correct.

That last section is the one most often omitted and it is what prevents a workflow stopping at eighty percent. Define completion explicitly.

The temptation is to write one large document covering everything about a subject. It fails in both directions: it is loaded when only a fraction applies, and the relevant part is buried in material about something else.

Split by task. If the trigger conditions are different, they are different skills, even where the subject is the same.

Keep each one short enough to be read in full. A long skill is subject to exactly the attention problem that a long instruction file has, and the solution is the same: delete anything that is not actionable.

When a workflow changes, the skill changes with it in the same sitting. Deferring this is how skills become traps — the process is now different and the document says otherwise, with more authority than a vague memory would have had.

Also fold in new failures. Every time the workflow goes wrong in a way it had not before, that is a line in the traps section. The document gets better each time something breaks, which is the whole compounding mechanism.

Review them occasionally and delete the ones you have not used. An unused skill is context waiting to be loaded for no reason.

The moment to write a skill is while running the workflow, because that is when the traps are visible. Written afterwards from memory you get the happy path and lose the details that make it useful.

Keep a scratch file open and note every decision, every warning, every 'remember to' as it occurs. At the end, tidy it into the four sections. It takes ten minutes on top of work you were doing anyway.

One good skill changes how a recurring task feels permanently. Five of them change how the whole setup works.