The short answer
A Claude Skill is a folder of instructions, and optionally scripts and reference material, that Claude picks up on its own when a task calls for it. At the centre sits a single document called SKILL.md: a few labelled lines at the top saying what the skill is and when it applies, then ordinary written instructions underneath.
The point of it is to stop you retyping the same preferences at the start of every conversation. You write the brief once, put it somewhere Claude can reach, and it arrives by itself when it is relevant. Skills work across Claude.ai, Claude Code and the Claude API, and they need a paid plan with code execution switched on.
Skills arrived in October 2025 and the area is still moving quickly. Treat this article as the shape of the thing rather than a current specification, and check Anthropic's own documentation for what is required and available before you build something you intend to rely on.
What problem is this actually solving?
Here is the situation, and you will recognise it immediately if it applies to you.
Every new conversation, you rebuild the same scaffolding. Meeting notes start with decisions, then actions with a named owner and a date, then anything still unresolved. No bullet longer than one line. Never the word synergy. You type some version of that paragraph, the work comes out right, the conversation ends. Tomorrow you open a fresh one and type it again.
If you have done any context engineering, you already have half an answer: keep a standing brief in a note somewhere and paste it back in when a session drifts. That genuinely works, and for a lot of people it is enough. Its weakness is that you are the delivery mechanism. The brief only gets used when you remember to use it, which on a bad Thursday is never.
A skill is the durable version of the same idea. Same brief, same words, but it is no longer your job to carry it into the room.
So what is a skill, in plain terms?
A folder. That is honestly the whole shape of it.
Inside the folder sits a document of instructions, and next to it anything that document needs: examples, reference notes, a small helper script if the job wants one. It is not software you install and it is not a settings screen you fill in. If you can write a handover note for the colleague covering your holiday, you can write a skill, because that is very close to what you are writing.
The instruction document is SKILL.md. It has two halves. The top is a small labelled header, rather like the fields at the top of a form: a name for the skill, and a description saying when it applies. Everything below that is plain markdown, which is to say ordinary writing with the occasional bullet point.
meeting-notes
SKILL.md the instructions, with the labelled header at the top
examples.md optional: two notes that came out exactly right
house-style.md optional: anything long you want kept separate
In plain English
- Skill:
- A folder of instructions and supporting files that Claude picks up when a task matches it.
- SKILL.md:
- The instruction document at the centre of the folder. Plain writing, not code.
- Description:
- The line in the header saying when the skill applies. It decides whether the skill is ever used.
- Progressive disclosure:
- Claude reads only names and descriptions up front, and opens the full instructions when a task matches.
- Code execution:
- A setting on paid Claude plans that skills require. You switch it on. You do not write code.
Does having several of these slow everything down?
This is the sensible worry, and the answer is no, for a reason that changes how you should write them.
At the start of a session, Claude reads only each skill's name and description. Nothing else. Picture a shelf of ring binders: it reads the spines and no more. When a task matches one of those descriptions, that binder comes down off the shelf and gets opened, and only then do the full instructions arrive.
That is progressive disclosure, and its consequence is unexpectedly generous. A skill can be long. Worked examples, awkward exceptions, the three edge cases your team argues about every quarter: none of it costs you anything until the moment it becomes relevant. So write the instructions properly rather than compressing them into something terse and ambiguous.
READ AT THE START OF EVERY SESSION
the name of each skill
the description of when it applies
READ ONLY WHEN A TASK MATCHES THAT DESCRIPTION
everything else in the document, however long it runs
The trade is that the description now carries an enormous amount of weight. It is the spine of the binder, and it is the only part guaranteed to be read. If it does not say clearly when the skill applies, the binder never comes down, and everything you carefully wrote inside stays invisible while you wonder why nothing has changed.
The honest test: do you need one?
Skip the feature list and use this instead.
Have you explained the same preference three times? Not a similar preference. The same one. If you have told Claude three separate times that you want dates written out in full, or that your reports open with the decision rather than the background, you have found something durable and it deserves to be written down once.
Three is the number for a reason. Once is a one-off. Twice is a coincidence. Three times is a pattern, and patterns are exactly what a skill is for.
Is it a preference rather than a fact? Skills are good at how you like things done. They are not a filing cabinet for information that changes weekly. If the thing you keep retyping is this quarter's figures, a skill will quietly go stale and start being confidently wrong at you.
Would you recognise it being ignored? If a skill fires and produces something subtly not-quite-right, you need to be able to notice. Anything where you cannot tell good output from bad output is not ready to be automated, whatever the mechanism. That principle sits underneath everything in AI that does the work, and skills do not exempt you from it.
Who should not bother
Two groups, and there is no shame in either.
People who have not hit the repetition problem yet. If you use Claude a few times a week for varied one-off tasks, there is nothing durable to record. A skill would be a file you wrote once and then forgot you owned. Come back the third time you catch yourself typing the same paragraph.
People who will resent maintaining a document in a folder. This is a fair preference rather than a failing. Everything else in modern AI happens inside a chat box, and a skill asks you to keep and occasionally edit a file. If that sounds like a chore, keep a standing brief in a note instead. You get most of the benefit and none of the upkeep.
Worth knowing before you write anything from scratch: Anthropic has open-sourced 17 official Agent Skills, covering creative design, document creation, technical development and enterprise communication. Reading somebody else's is the fastest way to understand the format, and occasionally the fastest way to discover you did not need to write one at all.
If you decide you do want one, our free Claude Skills course takes you from your first borrowed skill to writing and maintaining your own. If you are earlier than that, context engineering covers the standing brief version. And if you want to see the whole map, start here.