Write down how you work, once

Every organisation has a handful of tasks that are done slightly differently by every person who does them. Reviewing a quote. Onboarding a new client. Writing the monthly report. The steps live in a few people's heads, and the quality of the result depends on which of those people happened to pick up the work.

The expensive version of tribal knowledge

This is usually tolerated because writing it down feels like bureaucracy. Process documents get written once, saved to a drive and never opened again. Everyone knows how that ends, so nobody starts.

What changed is that a written-down process is no longer just a document for humans to ignore. It is now something a machine can follow. A skill is exactly that: a written instruction, in plain language, that the language model picks up when the task comes round.

What a skill actually contains

Less than people expect. A useful one is often a page:

• When to use it. The trigger. "When a customer sends a quote request for over a certain volume."
• What to look at. The sources that matter. The price list, the terms, the customer's history.
• The steps. In order, in the words your organisation already uses.
• What good looks like. One or two real examples of a finished result.
• What to escalate. The cases a person has to decide, stated plainly.

The last one is the part that gets skipped and matters most. A skill that never says "stop and ask" produces confident work on cases it should have handed over.

Why writing it down pays twice

The obvious return is that the task gets faster and more consistent. The less obvious one is that the act of writing it down surfaces disagreement. Two people describe the same process differently, and it turns out they have been doing it differently for years. That conversation is worth having whether or not a model is ever involved.

There is also a practical benefit: the skills belong to you. They sit in your own repositories in plain text, a person can read and correct them, and they do not stop working when you change model or vendor. They are not a configuration in someone else's product.

Starting without a project

The failure mode here is turning this into an initiative. It does not need one.

Pick one task that is done at least weekly, that has a right answer, and that currently depends on one person. Write down how that person does it. Run it against last month's real cases and read the results honestly. Adjust the wording where the output went wrong, which it will.

That loop takes days, not quarters, and at the end you have one task that works the same way every time. Then pick the next.

Next step

The best candidates are usually obvious to the people doing the work and invisible from above. Asking a team which task they would least like to explain to a new hire tends to produce the list immediately.