I had a discovery-brief prompt I was quietly proud of. It lived in a Google Doc, and I pasted it before every call. Then a teammate copied it, tweaked a line, and pasted their version. Then someone copied theirs. Six weeks later we had four subtly different briefs, one of them still referencing a value prop we had killed, and no one could say which was the real one. The play had not gotten better. It had played telephone with itself.
Skills fixed that. A skill is the play written down once, in a file, that Claude loads on its own when the work comes up. One source of truth, run the same way by everyone, that improves when you improve the file instead of drifting when someone copies it. This is how a team's best moves stop evaporating.
A skill is a procedure Claude loads itself
A skill is a small folder with a SKILL.md file at its center, plus any supporting files it needs. The file describes one task and how to do it well: the inputs to expect, the steps to follow, the standards the output must hit. When a task matches, Claude loads the skill, follows it, and hands back your version of the work.
The important word is itself. You do not paste a skill. Claude decides to load it based on what you are doing, the way a good colleague reaches for the right checklist without being told. That is what separates a skill from a prompt you keep on a sticky note.
Skill vs prompt vs command vs project
Four things sound similar and do different jobs. A prompt is a one-off sentence for right now. A custom command is a play you invoke on purpose, by name, when you want exactly that. A skill is a procedure Claude loads on its own when the task matches. A project is the standing context a whole body of work lives in.
The line that matters most is command versus skill. Reach for a command when you want to trigger the play yourself, /prep-call, now. Reach for a skill when you want Claude to recognize the situation and apply the right procedure without you naming it. Most teams end up with some of each.
- A one-off ask, just this once Prompt
- The same task, done the same way every time Skill
- Persistent context for a whole body of work Project
What goes in a good SKILL.md
A good skill reads like a runbook you would hand a sharp new hire: what this task is, when to use it, what inputs to expect, the steps, and the standards. The standards are the part people skip and the part that matters most, your voice rules, the length limits, the never-invent-a-stat line. Those are what make the output yours and not generic.
Keep it to one job. A skill that says how to write a discovery brief is loadable and reliable. A skill that says how to do all of sales is loaded for nothing and trusted for less. If you are tempted to add a second job, that is a second skill.
How Claude decides to load it
Claude chooses a skill mostly from its description, the short line that says what it is for. This is the highest-value sentence in the whole file, and it is easy to waste on a title. Write the description as the trigger: the situation in which Claude should reach for this, in the words the task will actually show up as.
Get this wrong and you get two failure modes. A vague description means the skill never loads when it should. An overbroad one means it loads when it should not, and now your discovery-brief skill is trying to help with a pricing question. Precise trigger, precise loading.
TipWrite the skill's description as when to use me, not what I am. That one line decides whether Claude ever reaches for the skill at the right moment.
Where skills live and travel
Skills can be personal, living in your own config, or shared, living in the project so anyone who works in that repo has them. For a team play, put it in the project. That is the entire point: the discovery brief stops being your prompt and becomes the team's skill, versioned in the repo, improved in one place.
Because it is a file in the repo, it also gets the benefits files get: review, history, and the ability to fix it once. When positioning changes, you edit the skill, and every future brief is correct. No one has to remember to update their copy, because there are no copies.
There is a review benefit too. Because a shared skill is a file in the repo, a change to it goes through the same look-before-it-ships path as any other change: someone can see the diff, catch a rule that got loosened by accident, and keep the team's best play from quietly degrading. A prompt in someone's notes gets none of that, which is how good plays rot without anyone ever deciding they should.
Skills are how a team scales its best play
The strategic version of this: your best operator has plays in their head that the rest of the team approximates. A skill is how you get those plays out of one head and into the tool, so the whole team runs the good version. It is enablement that actually enforces itself, because the standard is in the file, not in a training deck nobody reopens.
This compounds. Every play you turn into a skill is one more thing that runs consistently without a person policing it, and one more thing you can improve for everyone at once. A team with ten sharp skills is running ten of its best moves by default.
The discovery-brief skill, walked through
To make the anatomy concrete, take the skill I actually run. It has one job, prep me for a call, and a description written as the trigger, so Claude loads it whenever I am heading into a discovery meeting, without me naming it. Inside, it lists the inputs it expects, the account's site and our last transcript, and the exact output it produces: priorities, two risks, three questions, one specific thing to reference.
The part that makes it mine rather than generic is the standards section: peer-to-peer voice, no hype words, one screen maximum, never invent a stat. Those lines are why the brief comes back sounding like our team and not like a template. And because the skill reads our live positioning doc rather than a pasted copy, it stays correct when positioning changes. One job, a trigger, real inputs, and standards, that is the whole recipe, and it is a file the whole team now runs.
Where skills go wrong
The kitchen-sink skill is the classic mistake: one file trying to cover everything, so its description is vague and it either never loads or loads for the wrong thing. Split it. One job per skill keeps each one loadable and trustworthy.
The other is the write-once-and-forget skill. A skill that encodes last quarter's positioning will confidently produce last quarter's brief. Skills need the same maintenance as any standing context: when the truth changes, change the file. A stale skill is worse than no skill, because it is wrong with authority.
- The kitchen-sink skill: too many jobs, vague description, unreliable loading.
- A description written as a title instead of a trigger, so it never loads at the right time.
- A stale skill encoding old positioning, producing confidently outdated work.
- Keeping a great skill personal when the whole team should be running it.
The GTM version
The play I lost to the copy-paste telephone game is now a skill in our repo. It has one job, a description written as the trigger, our voice rules baked in, and it reads our live positioning doc rather than a snapshot. When I prep a call, Claude loads it without me asking; when a teammate does, they get the same brief; when positioning shifts, I fix one file.
That is the whole promise: your best move, out of your head, run the same by everyone, improved in one place. Which of your plays is currently living in a Google Doc and quietly drifting?
How to set it up
Create the skill folder
A skill is a folder with a SKILL.md inside. Put it in the project so it travels with the repo and the whole team gets it.
Write the procedure and, crucially, the trigger
Write the runbook inside: the job, the inputs, the steps, and the standards. Start with a description line written as when Claude should reach for it, because that is what makes it load:
"Use when preparing for a sales call or discovery meeting. Reads the account's site and our last transcript, then produces a one-screen brief: their priorities, two deal risks, three questions, one specific thing to reference. Voice: peer to peer, no hype words. Never invent a stat."
TipThe description is the most important line in the file. Write it as the situation, not the title, or Claude will not know when to use it.
Let Claude load it
You do not paste a skill. Start the relevant task and Claude reaches for it on its own:
Improve it in one place
When positioning or your standards change, edit the SKILL.md, not fifteen copies. Because there is one source of truth in the repo, every future brief is correct the moment you save, and no one has to remember to update anything.
Frequently asked questions
What is a skill in Claude Code?
A small folder with a SKILL.md file that teaches Claude how to do one task well. Claude loads it on its own when the task matches and follows the procedure inside.
How is a skill different from a custom slash command?
You invoke a command on purpose by name; Claude loads a skill on its own when the situation matches. Use a command to trigger a play yourself, a skill to have Claude recognize when to apply one.
What makes Claude actually load a skill?
Mostly its description, the line that says what it is for. Write it as the trigger, the situation in which Claude should reach for it, or it will not load at the right time.
Where do I put a skill so my team gets it?
In the project, so it lives in the repo and travels to anyone who works there. That turns your prompt into the team's shared, versioned play.
How big should a skill be?
One job. A skill focused on a single task loads reliably and stays trustworthy. If you are adding a second job, make a second skill.
Can a skill enforce our voice and rules?
Yes, and that is much of the point. Bake your voice rules, length limits, and never-invent-a-stat standards into the SKILL.md so every run produces your version, not a generic one.
What happens when our positioning changes?
Edit the one SKILL.md. Because there are no copies, every future run is correct immediately. This is why a stale skill is dangerous: fix it when the truth changes.
Are Claude Code skills the same as skills in the Claude apps?
Same idea, a SKILL.md procedure Claude loads on demand. Claude Code is one place they run; the concept carries across surfaces. See the Core Concepts guide on skills for the fuller picture.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.