AI Skills for Teams

Why your team gets five different answers from the same AI

If you manage a team that has started using AI, you have probably noticed something odd. Everyone has access to the same tool. Everyone is doing broadly the same job with it. And the output varies wildly depending on who typed the request.

One person gets a draft that is nearly usable. Another gets something so generic it would suit any company in the country. A third has quietly gone back to doing it by hand because the editing took longer than writing. Same tool, same task, three different outcomes, and no obvious reason why.

The reason is that all the context lives in people's heads, and it goes into the chat window differently every time. Working with a general-purpose AI assistant is like hiring a sharp graduate who forgets everything the moment they leave the building. Every conversation starts from nothing. So your best people write long, careful instructions and get good results, your less confident people write short ones and get poor results, and the quality of your output tracks the quality of somebody's typing rather than the quality of your process.

There is a fix for this, and it has a slightly grand name: AI Skills. Not skills in the training sense - this is not about sending anyone on a course, and it is not about how capable your people already are. A Skill is a specific thing with a specific format, and the name oversells it. The idea is simple and it works. The setup costs more than anyone mentions, which is the part I want to spend most of this on.

What a skill actually is

Strip away the jargon and a skill is a folder. Inside it sits a plain text file called SKILL.md, written in Markdown, which is just ordinary text with a few hash symbols for headings. That file holds the instructions you want followed. Alongside it you put whatever the job needs: your tone of voice document, a report template, a checklist, last year's figures.

It is the induction pack you would hand a new starter. You would not sit someone at a desk, point at a screen and say "do marketing". You would give them the folder. This is that folder, digitised, and the AI reads it before it starts work. Your team member types a normal request. The instructions get applied behind the scenes, the same way every time, whoever is asking.

You might reasonably ask why this beats pasting your guidelines into the chat window. Two reasons. The obvious one is that nobody will do it consistently. The less obvious one is that it does not work well even when they do: bury an important rule on page nine of a wall of pasted context and it gets skimmed past, roughly the way a person skims a long document and misses things.

Skills avoid that through something called progressive disclosure. Your AI does not load every skill you own at the start of every conversation. It reads only the names and one-line descriptions, which costs almost nothing. When someone asks for a quarterly report and one of those descriptions mentions quarterly reports, it opens that folder and reads the detail. Nothing else gets loaded. You get the full instruction set applied properly, without the cost or the noise of carrying it everywhere.

Two layers, and most people skip the first

Before you build anything, separate two things that get muddled together.

The first is personal context. Who you are, what your role actually involves, how you like to be communicated with, what you are ultimately trying to achieve. That moves slowly. It does not change from one task to the next, and often not from one year to the next, though it does shift when your role does. It applies whether you are drafting a proposal or arguing about pricing, and its absence is the reason a first answer so often sounds like it was written for someone else entirely. This layer does not need a skill at all. Four short markdown files called Who, What, How and Why will cover it. That is the Core Four.

The second is task context. The template for this particular report, the checklist for this particular process, the rules that govern one deliverable and nothing else. That is what a skill is for, and it is why skills work better narrow than sprawling.

Get the first layer in place before you start on the second. Skip it and every skill you write ends up re-establishing the same basics, which you then have to maintain in five places at once.

The part that is harder than it looks

Here is what happens when your team sits down to write its first skill.

You open the file. You type a heading. And you discover that the process you were going to document does not exist. There is a thing your people do, differently each time, held together by judgement nobody has ever had to put into words. You have been making decisions on the fly for years and calling it a process.

There is a question hiding behind all of this, and it is the one that stops most first attempts. Does the business process actually exist?

You cannot model a process that does not exist. AI can only model a process that is clearly defined, and if yours is not, you will get useless output - fluently written, correctly formatted and useless.

I saw this with a manufacturer making made-to-order units for the building trade, a few hundred people, family-run and profitable. Customers ring constantly to ask where their job stands, and whoever picks up the phone has to go and find out. An obvious candidate for a skill: pull the job status, draft the update, send it. So we sat down to write the instructions, and inside ten minutes we were stuck on a question nobody had ever asked out loud. What does "finished" mean?

The person handling invoicing had a clear answer. A job is done when the final payment lands. There might be small outstanding items, but her part is over. The person handling scheduling had an equally clear and completely different answer. Payment has nothing to do with it. There are still fixes outstanding on site, somebody has to track them, and the job is live until they are closed. Both had held those positions for years. Neither had any idea the other disagreed, because the question had never been written down anywhere it could be compared.

That single unanswered question was why customers were getting inconsistent answers on the phone, and no amount of clever prompting was going to fix it.

Writing the skill file took under an hour. Deciding what should go in it took most of an afternoon and involved a mild argument. That ratio holds almost every time, and it is the most useful thing I can tell you before you start. The AI is not the bottleneck. The undocumented judgement is.

This is also why the first attempt so often disappoints. Someone writes a skill that says "use our brand voice and follow best practice", gets mediocre output, and concludes the technology is overhyped. But that skill contains no information. It is a vague brief handed to a competent stranger, and a human would produce something mediocre from it too.

The upside is that once those decisions are made, everyone inherits them. A senior person spends an afternoon working out what good looks like, and from then on your newest hire triggers the same skill and produces work to the same standard. For a manager, that is the real prize. It is not the minutes saved on any single task. It is that your quality stops depending on who happened to pick up the job.

Where this gets awkward

Three things are worth knowing before you commit a weekend to this.

Triggering is fussier than you expect. A skill fires by matching the request against its one-line description. Write that line vaguely and the skill sits there unused while people wonder what went wrong. Write it too broadly and it barges into conversations where it was not wanted.

They go stale silently. Change your report format and the skill will confidently keep producing last quarter's layout. Nothing warns you. The output still looks finished, which is precisely what makes it expensive.

They are the wrong tool for thinking. Guardrails are exactly what you do not want when someone is exploring a problem or trying to be surprised. Use skills for the deliverable, not for the discovery.

One correction on security, because the opposite is often written. Wrapping work in a skill does not put a private perimeter around your data. Your files still go to whichever AI provider you use, under whatever terms you signed, and if data residency matters to you that is a question about your contract and deployment rather than the file format. The genuine risk points the other way: skills can include executable scripts, and researchers at Cato Networks showed that this could carry malware in a skill written by someone with bad intentions. Downloading a skill from a public repository is closer to installing software than to copying a prompt. Read anything you did not write before you turn it on.

How to pick your first one

Start with the paper cuts. The small, repetitive, mildly irritating jobs that recur every week - the standing update email, the report that always needs reformatting, the meeting notes nobody wants to write up.

Then do this before you write a word of the skill. Pull up the last three times your team did that task. Put them side by side and find where they differ. Those differences are the decisions nobody has made yet, and they are the actual content of your skill. Everything else is scaffolding.

Write it as though you are briefing a capable new hire who cannot ask you follow-up questions. Include the templates. Include the mistakes to avoid, because negative instructions do a surprising amount of work. Then run it on three real jobs, not invented test cases, and fix what breaks.

One skill, one task, tested properly, will teach your team more than a library of twenty nobody validated.

And the afternoon you spend arguing about what good actually looks like is not overhead. It is the conversation you have been putting off for years, and this is the first thing that has given you a reason to have it. The skill is almost a by-product. What you are really building is the answer to "what does finished mean" - written down, in one place, where two people who disagree can finally see that they do.

-- Alastair

If you want that conversation to happen across a whole team rather than one enthusiastic person, that is roughly what my Team AI Adoption programme is for. Four to six weeks, cohort-based, and a good chunk of it is this exact work of getting the process out of people's heads and into something everyone can use.

P.S. The Core Four is the subject of my latest book, Hello! I'm New Here - four simple files that stop you starting from zero every time you open a new chat. There is a free starter guide if you would rather try it before buying anything.