Claude Skills: What They Are and How to Build Your First One
A Skill is a reusable instruction pack that teaches Claude how your business does a specific task — how you format a proposal, structure meeting notes, apply your brand, build the monthly report. You write it once in plain language, no coding, and from then on Claude pulls it in automatically whenever that task comes up.
If a Project holds your knowledge, a Skill holds your method— and unlike a Project, a Skill follows you everywhere Claude works. It is an open standard, available on any plan, and the closest thing there is to writing down how your company actually operates.
What a Skill actually is
Think about what you explain to every new hire in their first fortnight. Not facts about the business — the method. How we structure a proposal. What goes into a client update and in what order. How we write a case study. The checks before anything goes out.
That knowledge usually lives in three senior people's heads and gets transmitted by correction: someone produces a draft, someone more experienced fixes it, and over a year or two the method is absorbed. A Skill is that method, written down once, in plain English, applied automatically.
The important word is automatically. You do not have to remember a Skill exists or paste it into anything. When a task calls for it, Claude reaches for it — the way a colleague who knows the house style simply uses the house style.
Skill or Project? The test
These are the two features people conflate most, and the distinction is simple once you have the test.
| Project | Skill | |
|---|---|---|
| Holds | What Claude should know | How Claude should work |
| Contains | Your documents and standing context | A method — the steps and rules for one task |
| Applies | When you are working inside that Project | Everywhere, whenever the task comes up |
| Analogy | The onboarding pack | The recipe |
The test: if you keep re-uploading the same document, you want a Project. If you keep re-explaining the same process, you want a Skill. Most teams need both. Most have neither.
Building your first one
The mistake is trying to write a Skill from scratch in the abstract. Do it backwards, starting from work you have already done well.
- Find three good examples of the output. Three proposals you were happy with, three well-structured updates. Real ones.
- Ask Claude what they have in common. Give it all three and ask it to describe the structure, tone, order of argument and rules they share. It is very good at this, and it will name things you do instinctively but have never articulated.
- Correct what it got wrong. This is the real work, and the interesting part — you are putting your own method into words, often for the first time.
- Save it and use it for a fortnight. Every correction you make goes back into the Skill. After two weeks it is genuinely yours.
A workable shape for the file:
A “before returning it” block turns a Skill from a template into a quality gate. Most people write the structure and stop. Adding two or three checks the model runs before handing anything back is what changes the hit rate of the first draft — the difference between output you edit and output you rescue.
Which Skills are worth writing
The rule of thumb: something done often, done the same way, where the way matters. Anything failing all three is not worth writing down.
- The recurring client-facing document. Whatever your business produces constantly and cares about the quality of.
- Meeting notes in your format. Low glamour, large aggregate time saving, and the output is immediately checkable.
- Anything with a review or compliance step. Where the checks are the point and forgetting one is the failure.
- The thing only one person does well. The highest-value Skill in most organisations, and the most neglected.
The quiet organisational benefit
There is a second-order effect here that has nothing to do with speed, and I think it is the more interesting one.
Writing a Skill forces someone to articulate a method that has only ever existed as instinct. That is valuable whether or not anyone ever runs the Skill. Teams doing this reliably discover disagreements they did not know they had — two senior people who have been quietly doing the same task differently for years, each assuming theirs was the house style.
And the artefact outlives the person. When your best proposal writer leaves, the method leaves with them unless someone wrote it down. Nobody ever gets round to writing it down, because there is no forcing function and no immediate payoff. A Skill is that forcing function with an immediate payoff attached.
That reframing is worth carrying into the room. You are not configuring a tool. You are documenting how your company works, and getting a better first draft as the side effect.
Turning a team's best methods into Skills that hold up under real use is a large part of what a Deployed Kickstart half-day produces — built from your actual work rather than a template. The Partner programme is how the library grows and the good ones spread.
Frequently asked questions
What are Claude Skills?
Reusable instruction packs that teach Claude how your business does a specific task — how you format a proposal, structure meeting notes, apply your brand or build the monthly report. You write one in plain language with no coding, and from then on Claude pulls it in automatically whenever that task comes up, without you having to remember it exists.
What is the difference between a Claude Skill and a Project?
A Project holds what Claude should know — your documents and standing context — and applies when you are working inside it. A Skill holds how Claude should work, the method for one task, and follows you everywhere. The test is simple: if you keep re-uploading the same document you want a Project, and if you keep re-explaining the same process you want a Skill.
How do I build a Claude Skill?
Backwards, from work you have already done well. Find three good examples of the output, give them to Claude and ask what they have in common — structure, tone, order of argument, shared rules. It will name things you do instinctively but have never articulated. Correct what it gets wrong, save the result, and use it for a fortnight, folding each correction back in.
What should a Claude Skill contain?
When to use it, the structure of the output, the rules that must always hold, and — the section most people miss — a set of checks to run before returning anything. That last block turns a Skill from a template into a quality gate, and it is what changes the hit rate of the first draft from something you rescue to something you edit.
Which Claude Skills are worth writing?
Anything done often, done the same way, where the way matters — something failing all three is not worth writing down. In most companies that means the recurring client-facing document, meeting notes in your format, anything with a review or compliance step, and the task only one person does well, which is the highest-value and most neglected of the four.
Do Claude Skills have benefits beyond speed?
Yes, and arguably a larger one. Writing a Skill forces someone to articulate a method that has only ever existed as instinct, which reliably surfaces disagreements a team did not know it had — two senior people doing the same task differently for years, each assuming theirs was the house style. The artefact also outlives the person: when your best proposal writer leaves, the method leaves with them unless somebody wrote it down.
Found this useful? Send it to someone who needs it.