Codify the judgement; the file is easy
What a skill is
A skill in this sense is a small document that an assistant reads before performing a particular kind of task. It states the goal, the criteria for a finished result, the steps in order, the recurring mistakes worth flagging, and the reference material that should be consulted. The format is plain text. The discipline is in the writing, not the syntax. A worker who has written one well-considered skill file has done the cognitive work that allows the assistant to be useful on that category of task at all; everything afterward is reuse.
The codify-before-build rule
The most consequential rule in this area is simple and routinely ignored. Write down what good looks like before you ask an assistant to produce it. Write it down in plain language, with examples if possible, and revise it until a competent stranger could use the document to judge an output without needing to ask further questions. Only then build the skill. The reason this rule matters is that the assistant cannot supply the judgement that defines good — it can supply almost everything else, but the standard has to come from a person who already meets it. Skipping the codification step puts the worker at the mercy of whatever the average looked like in the training data.
The five-step build
A reliable pattern for the build itself has five steps. Pick a task you do at least weekly. Sit yourself down, or have the assistant interview you, on the goal of the task, the standard that defines a finished result, the mistakes that recur, and the reference material the work draws on. Decompose into steps as in the previous lesson. Ask the assistant to draft the skill file based on that interview and the steps. Run it on the next time the task arrives and adjust. The cycle repeats whenever the skill misfires. None of the five steps is difficult. The discipline is that all five happen, in this order.
Improve in the loop, not in advance
A new skill is rarely perfect on the first run. The instinct to refine it before letting it out of the test environment tends to produce skills that are over-specified for cases that never occur. The opposite instinct is more useful. Let the skill go live early. Notice what it gets wrong on a real instance. Update the file with the correction. Re-run. After three or four cycles the skill is hardened against the cases that actually arrive, rather than against the ones imagined in advance. This is the practical meaning of improving in the loop: the cases that matter are the cases that have happened, and the skill that improves against them is the one that compounds.
A working pattern observed in production teams
The pattern that internal teams converge on, observed in published descriptions of working practice at a large model laboratory, has the same shape regardless of which department adopts it. A domain specialist — a lawyer, a marketer, a researcher — writes one skill file containing their criteria for a category of work they perform repeatedly. The skill is installed on a familiar surface the rest of the team already uses; in published accounts, this is usually the team's chat application. Colleagues invoke the skill by name and receive a first pass that the specialist would have given them, only faster and without consuming the specialist's attention. The specialist reviews the final output before it leaves the organisation. In one published account, this arrangement removed roughly four-fifths of the routine work in a pre-release legal sign-off, leaving the genuinely contested calls — the remaining fifth — to the specialist's full attention.
Think of one piece of work you do well that a junior colleague would struggle with. What do you actually know that they do not?