In full
Every firm has a version of the same dependency. One person does the quarterly analysis properly. One person knows which checks matter on a new client file. One person writes the report the partners actually read. The method exists, but it lives in a head, and the quality of the output depends on who picked up the work.
Pick one job that is done often, done inconsistently, and has a recognisable right answer. Have the person who does it well describe how, in prose, including why each step exists. Run it, then correct it wherever the output is wrong, and keep correcting for several cycles: that loop is the work, not the first draft. Give it a named owner and a review date, because a written method rots exactly the way a runbook does.
What a skill actually is
A skill is that method written down in a form an AI assistant can follow: a folder with a set of instructions, plus any supporting material the job needs. The assistant reads the short description of every available skill, and reads the full contents only when the task in front of it matches. That loading behaviour is the practical bit, because it means an organisation can hold a large library without every request carrying the weight of all of it.
The result is not a smarter assistant. It is a more consistent one. The same request produces the same shape of output regardless of who typed it or how they phrased it.
The value is not that the model gets better. It is that the output stops depending on who asked.
What it is good for
- Procedures with a right answer. Onboarding checks, file reviews, standard reports: work where consistency is the quality bar.
- House style and structure. The format your documents take, which is usually well understood and poorly documented.
- Knowledge that is expensive to rediscover. The reason a step exists, which is the first thing lost when someone leaves.
- Anything you have explained more than three times. That repetition is the signal.
Where it goes wrong
Two failure modes are common enough to plan for.
The first is over-specification. A skill that scripts every step for a task requiring judgement produces worse results than a shorter one that states the goal, the constraints, and how to tell whether the output is right. Capable models plan competently; hand-written scripts get in the way. Prescriptiveness is right for the narrow, fragile steps and wrong for the open ones.
The second is rot. A skill that hard-codes a path, a version number, or a system that has since changed will keep confidently applying instructions that no longer match reality. Skills are documentation, and documentation decays. Somebody has to own them the way somebody owns a runbook.
The governance angle
For a regulated business there is a second argument, and it is stronger than the productivity one. A skill is a versioned artefact. You can see what it says, when it changed, and who changed it. That is a materially better position than an undocumented practice that lives in individual habit, and it is a far better position than a set of ad hoc prompts nobody has read.
It also gives you somewhere to put the constraint. If a piece of work must never include a certain claim, must always record a particular check, or must be handled in a particular jurisdiction, that belongs in the written method rather than in the memory of whoever is doing it.
How to start
Pick one job that is done often, done inconsistently, and has a recognisable right answer. Have the person who does it well describe how, in prose, including the reasons behind the steps. Use it. Correct it where the output is wrong. That correction loop is the work, and it is worth more than the first draft.
Resist starting with the hardest, most judgement-heavy thing you do. That is where the method is least written down and the standard hardest to state, which makes it the worst first attempt and the most likely to convince a sceptical team that the whole idea does not work.
A skill captures how a job should be done and loads when the task calls for it, so output stops depending on who picked up the work. State goals and constraints rather than scripting judgement, and give the skills an owner: they are documentation, and documentation rots. For a regulated firm the strongest argument is not speed, it is that a versioned written method is easier to evidence than an undocumented habit.