Naming a Claude skill: what the name does and what it does not
A skill's name identifies it and lets you ask for it directly; the description decides when it is picked. How to choose a name that helps and never hurts.
It is tempting to spend a long time on a skill's name. It is worth a few minutes, not an afternoon, because the name and the description do different jobs.
| Field | Job |
|---|---|
| name | Identifies the skill; how people ask for it directly |
| description | Decides whether Claude picks it for a request on its own |
A good name
- Lowercase with hyphens, matching the folder:
glass-instrument-ui. - Names the result, not the stack:
release-notes, notgit-log-parser. - Short enough to type when you want to invoke it yourself.
- Unique among your installed skills, so asking for it by name is unambiguous.
Naming the skill in a prompt is also the fastest diagnostic you have: if it works when named and not otherwise, the name is fine and the description is the problem. That test, and the fix, are in why a skill does not fire and how to write a skill description.
Questions
What format should a skill name use?
Lowercase letters, numbers and hyphens, short, and the same as the folder name. It keeps the skill easy to reference and avoids surprises across operating systems.
Does a good name make a skill trigger more often?
Mostly no. Automatic selection leans on the description. The name matters when a person asks for the skill by name.
Should the name describe the technology or the job?
The job or the result. People ask for outcomes, and a name like editorial-ledger-ui tells a reader what they get, where a tool name tells them how it is built.