I often describe AI as a very capable intern. It is knowledgeable, resourceful and willing to do a great deal of work. But it has just walked in. It doesn’t know how your team makes decisions, which source you trust or what you consider a useful recommendation. Giving it the role of “expert product manager” does not give it your experience of this particular product, company or way of working.
Much of that experience appears in the corrections we make. “This was a proposal, not a decision.” “That number needs a different denominator.” “There isn’t enough evidence to make this recommendation.” We explain, the agent tries again and eventually the output becomes useful. Then we start another session and repeat parts of the explanation. Somewhere inside these conversations is a working method that we have not yet made explicit.
An agent skill is a way to preserve that method. As Anthropic explains in its original Agent Skills guide, it is a folder with a file called SKILL.md, containing instructions and a description of when to use them. It can include examples, templates and scripts. A compatible agent loads the relevant instructions when needed. The format is simple. The harder work is deciding what we need to teach it. That is the focus of my Agents and Agent Skills Workshop (next cohort on 8th October).
A useful starting point is a task you have already worked through with an agent. Look at the steps that helped and the corrections that changed the output. Another is material you already use: a checklist, a runbook or examples of good work. You can also adapt a skill someone else has built, provided you examine its assumptions. Asking an agent to create a skill from a task name alone gives it very little of the knowledge you are trying to preserve.
Consider a meeting follow-up. The agent already understands what a summary is. What it may need to learn is that volunteering to investigate a question is different from committing to deliver a feature. Or that an owner should remain unspecified when nobody agreed to take responsibility. These details belong in the method, along with what to do when the information is missing. In my workshops, I call these “gotchas”: mistakes worth documenting so that we don’t have to keep discovering them. A vague instruction to be accurate is much less useful than explaining the error we want to avoid.
But writing the instructions is only part of the work. In an earlier workshop, we built a launch-copywriting skill that worked from project material and produced drafts for email, LinkedIn and X. We compared the output with and without the skill. The comparison showed where the skill helped, where the agent was already doing well and the extra effort involved. At one point, the agent gave its own work a perfect score. That was a useful reminder to inspect the output ourselves.
A skill should earn its place in the workflow. Run it on a few representative examples, including something different from the material used to build it. Does it prevent the mistakes you care about? Does it reduce the correction required? When a recurring failure appears, revise the instructions and check again. A correction made in conversation does not necessarily become a correction in the skill file.
For a team, this turns part of its experience into something colleagues can inspect, challenge and improve. The method still needs an owner, and it will change as the work changes. But the knowledge is now available beyond the person who originally developed it. I think this is one of the more useful ways to amplify expertise: understand the judgement inside your work, explain it clearly and test whether someone - or an agent - can use it.
In the Agents and Agent Skills Workshop (next cohort on 8th October), we’ll build, install and evaluate a skill around a real workflow. You can also watch my free lightning lesson on agents and agent skills for a walkthrough of how to turn a working method into a skill an agent can use.