Teaching an assistant how your firm does something

Somebody in your organisation has probably worked out how to get an AI assistant to do a particular piece of work properly. They have the prompt, a few examples that show what good looks like, the reference material it needs, and a list of things it should never do. What comes back is close to the work they would have produced themselves.

Nobody else has it. When that person is on leave the knowledge goes with them, and the work goes back to being done the slow way. That is an old problem arriving in a new place: knowledge that lives in one person. It now has a fairly practical answer.

What a skill is

A skill is a set of instructions kept where the assistant can find them, under a name and a one-line description of when it applies. The assistant reads that description, decides the work in front of it matches, and loads the rest. Nobody pastes anything. Alongside the instructions it can carry the things they refer to, such as a template, a checklist or a worked example, opened only when they are needed.

It is not simply a long prompt. The instructions arrive with the material they depend on, so nobody has to remember the right combination on the day. Think of it less as teaching an assistant everything about your business, and more as teaching it to do one job the way your organisation expects.

The file format differs between tools and will keep changing; it is not the interesting part. The shift that matters is where the instruction lives. It moves out of one person’s notes and into the thing doing the work, where it applies by default rather than by memory.

Start from a procedure you already have

The best skills are transcriptions rather than inventions. Sit with the person who does the work well and write down what they actually do: the order they do it in, what they look at first, the check they make before sending, and the point where the work needs judgement. A skill written from how the work is supposed to be done produces output that matches the process document and satisfies nobody.

A written procedure helps, but the real one is usually a little different from the manual. Real procedure includes the exceptions, and the exceptions are the reason it was worth capturing.

The description is the trigger

The name and the description do the entire job of getting a skill used. Everything else only matters once it has been loaded, and a skill that is never loaded may as well not exist.

Write the description as the moment of need rather than as a category. “When preparing a client report from interview notes” finds the work. “Reporting utilities” does not. Use the words the person would use in the moment, including the informal ones.

Keep the instructions short, and the detail beside them

Long instructions get followed unevenly, for the same reason a twelve-page process document does. Keep the main file to the shape of the task and the decisions that carry weight. Move templates, worked examples and long tables of rules into separate files that are opened when the work calls for them.

This is not only a matter of tidiness. What is not opened is not read, so it neither costs anything nor competes with the instruction that mattered. Material kept in its own file is also easier to correct when the template or the rule changes.

Write down what not to do

Most of the value in an experienced person’s judgement is negative. The approach they know not to take. The field they never fill in automatically. The client who is handled differently, and why. The point at which somebody has to make the call rather than the assistant.

A skill that describes only the straightforward path produces confident work that is wrong in precisely the ways your organisation cares about. The exceptions are the part nobody could have guessed from outside, and they are what makes the skill yours rather than generic.

One owner, and correct the source

A skill decays exactly as a knowledge base does. The template changes, a rule changes, and the instructions quietly go on describing last year’s process.

Give each one a named owner, not necessarily somebody maintaining it every week, but somebody who knows when the underlying process has changed. Then adopt the habit of fixing the skill rather than fixing the output. When somebody gets a result that is wrong in a repeatable way, the correction belongs in the instruction and not in that day’s document, so everybody who uses it next gets the benefit. That habit is the whole difference between a skill that is still true in a year and a folder of abandoned prompts.

Watch whether it gets used

Three questions tell you most of what there is to know:

• Are people reaching for it without being reminded?
• Are they rewriting most of what comes back?
• Do the same exceptions keep coming up?

The first two separate the failure modes, and they need different fixes. A skill that never gets loaded has a description problem: the work is happening and nothing is recognising it. A skill that gets loaded and produces work people rewrite has a content problem. The third question is usually pointing at a section nobody has written yet.

Ask the people doing the work. They will know immediately, and they are usually not asked. A skill should make the task easier, not add another system to work around.

What a skill will not do

It does not make an assistant know anything it could not otherwise find out. A skill is a procedure, not a source of facts: if the work needs your rates, your templates or last quarter’s numbers, the skill has to point at where those live.

It will not turn an unclear process into a good one either. Where the work changes every time, where nobody quite agrees what the right answer looks like, or where the decisions that matter rest on judgement nobody has made explicit, handing the work to an assistant reproduces the uncertainty faster. Get the process reasonably clear first, then teach the assistant the part that repeats.

Nor does it remove the review step. What it removes is the variation, so the first draft comes out the same whoever asked for it. That is a smaller claim than the one usually made for these tools, and a considerably more defensible one.

Where to start

Take work that happens every week, has a recognisable shape, and currently depends on somebody’s private habits for its quality. Choose the most repeatable case rather than the most ambitious one. Write one skill. Give it to two people who did not build it, and watch what they change: the second version is usually the one worth keeping.

The by-product is worth as much as the tool. At the end of it you have a written description of a process that until then existed only in a head.