What a skill actually is
Most people who use AI seriously have had the same quiet frustration: you explain the same context, the same tone, the same set of steps — and then you open a new chat tomorrow and explain all of it again. The thinking is good. The repetition is the waste.
A skill is how you stop repeating yourself.
If you have never thought of "skills" as a thing you can deliberately build, that is the gap this series closes. You are probably already doing the work a skill would capture — you have just been doing it by hand, every time, from scratch.
A skill is not a prompt
A prompt is disposable. You type it, Claude responds, and when the conversation ends the context goes with it. Start again tomorrow and you start from nothing — re-pasting the brand voice, re-describing the audience, re-listing the steps.
A skill is the opposite. It is a saved, reusable set of instructions and context for a recurring task. You define it once. Then you invoke it — and Claude already knows the process, the tone, the things you would otherwise have to re-explain. The prompt is the conversation. The skill is the capability behind it.
The difference is not length. It is ownership and reuse. A prompt is something you spend. A skill is something you keep.
A skill is not a project either
A project — a folder where you keep related conversations and reference files — is organisation. It is a useful place to put things. But a folder does not do anything. It holds context; it does not act on it.
A skill is capability. It tells Claude how to perform a specific recurring task, and it carries that knowledge with it whenever you call on it. You can keep your files in a project and still reach for a skill to do the work. They are not competitors. One is where things live; the other is how the work gets done.
What is actually inside a skill
A skill is, at its simplest, a set of written instructions Claude reads when the task matches — plus the context that makes those instructions specific to you. In plain terms, a good skill carries four things:
The process — the steps, in order. What to check first, what to produce, what to do at the end.
The context — the things that make the output yours rather than generic: your audience, your voice and tone, your constraints, the standing facts about your work that Claude would otherwise have no way to know.
The tools — where the relevant material lives, so the skill can pull from it rather than guess (your documents, your data, the systems you keep information in).
The instructions — the specific notes on how it should behave, including the questions it should ask you before it runs ahead.
You do not have to write all of this perfectly. Part of the point of a skill is that Claude fills in the obvious mechanics. Your job is to supply the part Claude cannot know on its own — which is exactly the context and judgment that make the work valuable.
Why this changes how you work
The shift is small to describe and large in practice: you stop re-feeding the same context, and you start owning a reusable version of your own process.
That is also why this is a Track 2 skill and not a developer trick. Nothing here requires code. The person who benefits most is the one with a recurring, judgment-heavy task — a project manager, a consultant, an operations or marketing lead — who has been doing that task well, by hand, and would like to do it just as well without starting from zero every time.
A prompt asks Claude to help you once. A skill captures how you work, so the help compounds.
What comes next
Knowing what a skill is does not tell you how to build a good one. The next part covers the method — how to go from a task you understand to a skill that holds up — and the one mistake that makes most first skills worse than no skill at all.
Next in this series: Part 2 — Context to skill: the method