Most people who use Claude regularly have a handful of jobs they explain from scratch every time. The weekly report. The way a client email should sound. The checklist a document has to pass before it goes out. Each time, they paste the same instructions, correct the same mistakes, and get roughly the same result after the same amount of effort.
That repetition is the most useful signal you have, because it tells you which work should become a skill.
A skill, in Claude's terms, is a short set of written instructions saved as a file, usually called SKILL.md, in a folder of its own. Claude reads a one-line description of every skill it has, and loads the full instructions only when the job comes up, or when you call the skill by name with a slash command such as /weekly-report. You write the procedure once, and from then on the skill runs the same way every time.
Anthropic's own guidance on skills puts the trigger plainly: "Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat." The same page explains why skills are so cheap to keep around: "a skill's body loads only when it's used." Loading only when used matters, because everything Claude carries all the time competes for its attention. I've written separately about why more context can make output worse.
I teach skill-building with four verbs, in order: catch, capture, codify, iterate.
Catch: notice what you keep repeating
Finding your first skill starts with listening to yourself. The phrases to watch for are these:
- "I keep having to remind Claude that…"
- "Every time I do X, I first have to explain Y."
- "Why does it always default to W when I want Z?"
The other signal comes from a job that finally goes well. When Claude finally gets something complex right after a long back-and-forth, that conversation is the raw material for a skill that gets it right first time next time.
In the AI Bootcamp, the session called "Turn a job into a button" opens with this same exercise. Everyone writes down, in their workbook, every job they did more than three times last month, then shares the list in the meeting chat. I cluster the pile aloud into three groups: worth making reusable, worth automating, and leave it alone. The leave-it-alone group matters. Some repeated work is quick enough, or rare enough, that a skill would cost more to maintain than it saves.
Capture: start from your transcripts
The worst way to write a skill is from a blank page, describing your process from memory. You forget the edge cases, because they live in what actually happened and you only remember the general idea. You also describe the trigger the way you think about it, which is rarely the way you actually phrase the request.
So capture the source material first, in this order of value:
- Your own Claude transcripts. Open your last few sessions on the job. Find the moments where you corrected Claude, where you repeated yourself, and where it solved something well after a struggle. Those excerpts show how the work really goes.
- Documents you already have. A style guide, a runbook, a checklist in Notion or Word. Point Claude at the document and ask what a skill built from it would trigger on.
- An authoritative outside source, when the skill needs knowledge nobody on your team has written down.
Codify: let Claude write the first draft
Once the source material is in front of Claude, you don't have to write the skill yourself. Anthropic publishes a skill called skill-creator that structures the instructions and refines the description Claude uses to decide when to load it. That description is the hardest part to get right, and it is where your own phrasing from the transcripts pays off.
A useful skill answers four questions:
- When does it trigger? The words or situation that should bring it in.
- What does it do? The smallest reliable sequence of steps.
- What does it need? The documents, sources or tools it may use.
- What does it hand back? An output you can inspect and check.
In the very first kick-off session, participants build a skill. They write a prompt that makes Claude ask clarifying questions before it starts work, save it, and after the break ask Claude to turn it into a skill called clarify. A few minutes later they type /clarify and it runs. None of it requires writing code. If writing code is your worry, I've answered it in more detail in can non-developers use Claude Code?
Iterate: version one will be slightly wrong
Every first version of a skill is a little off. There are three ways it goes wrong, and each has a different fix:
| What happens | What it looks like | What to do |
|---|---|---|
| The skill doesn't fire | Claude ignores the skill when you expected it | Add the trigger phrases you actually use |
| The skill fires too often | The skill loads on unrelated requests | Say when to skip it, and tighten the trigger |
| The advice is wrong | The skill loads, but the output is poor | Fix the instructions, and add examples and things to avoid |
The habit I want people to leave with is updating the skill the moment a conversation teaches you something it should have known. "Add that to the skill" is a perfectly good instruction to give Claude. Skills that never get updated slowly drift away from how the work is really done.
Narrow skills beat one that does everything
The most common mistake is building one big skill for a whole area of work. In the AI Bootcamp, I demonstrate the difference live. One general "review everything" request goes up against four focused reviewers, one each for brand, claims, grammar and audience. The group sees the difference for itself.
A narrow skill has one job and a small surface, so you can judge in a minute whether it did that job. The pattern has a name in the augmented coding patterns catalogue: Focused Agent.
Judge a borrowed skill before you trust it
You won't build most of your skills. Many already exist in marketplaces and published collections: skills for producing slide decks, Word documents and PDFs, for code review, for diagnosing bugs. The useful judgement is which one to reach for and how to tell a good one from a bad one.
The way I put it in the masterclass: a borrowed skill is context somebody else placed. So before trusting a borrowed skill, I ask people to run four checks:
- Read the instructions end to end. If you wouldn't accept them from a colleague, don't accept them here.
- Check what it is allowed to touch. A plugin can install commands, hooks and connections to other services, and it runs with your access.
- Check whether it asks you for missing decisions or invents them. A good skill stops and asks. A poor one fills the gap with a default and doesn't tell you.
- Run it once on something that doesn't matter. Then compare what it did with what it claimed it would do.
What changes when people do this
Several participants mentioned skills in the feedback they wrote at the end of the programme. A developer wrote:
"The introduction of skills and its reusability for me has been a game changer and managing context through proper prompts and /plan mode together with other techniques has been really helpful"
Someone from a product and business team described the same shift in plainer terms:
"I have been able to build skills that I can use for repetitive tasks and I have been able to refine my instructions to Claude and it has got better at doing what I ask."
The second quote is the one I'd point a business leader to. It describes the loop exactly: build the skill, refine the instructions, and the output improves.
From a pile of skills to an AI chief of staff
For a business leader, a set of good skills starts to look like an AI chief of staff. The skills draft email in your voice, pull a board pack together from the sources you already have, build the monthly report, and lay out a decision memo the way you think. The skills work only on what you hand them, and you decide what they may do without asking. Deciding what runs without you is its own discipline, which I cover in the same session as skills.
If you want to build that on your own work, with me there while you do it, have a look at the AI Bootcamp. The AI Bootcamp is eight live sessions, and you leave with skills built around jobs you really do.