Match the words people actually type, not the words you would write
People ask for outcomes in loose, lowercase, half-finished sentences. How to collect the phrasings your users really use and fold them into a skill description.
Skill authors write descriptions in the language of the skill. Users type in the language of the problem. A description that says "applies the design system" misses the person who types "can you make this look less like a template".
Collect real phrasings first
- Search your own prompt history for the job the skill does.
- Ask two teammates how they would ask for it, without showing them the skill.
- Read support questions and chat threads where people ask for this kind of help.
What the collection usually shows
| You wrote | People type |
|---|---|
| Applies the design tokens | make it look like the rest of the app |
| Generates release documentation | write the changelog for this |
| Audits accessibility compliance | is this readable, check contrast |
Put the right-hand column into the description, in natural sentences. Then check it with a set of real prompts, as in a trigger test set. If broad everyday words start pulling the skill into unrelated work, narrow it as in a skill that fires too often.
Questions
Where do I find how people phrase requests?
Your own history of prompts, your team's, support messages, and the questions people ask colleagues in chat. Those are the phrasings a skill has to match.
Should a description include slang or typos?
Include the common short forms people really use, such as 'make it look less generic' or 'dark mode'. Deliberate typos are unnecessary; matching is not that literal.
How many phrasings belong in a description?
Three to six of the most common, in natural language. The goal is coverage of how people ask, not a keyword list.