If I see something called "Proposal Genius," I still have to ask what it does. Does it write the proposal? Check the scope? Decide the price? Send it to the client?
The name leaves all of that open. And those are the things I'd want to know before using it.
Naming Capabilities helps you answer those questions in the name and description. Give it the instructions for a skill, the steps in a workflow, or a description of a service. It reads what the thing does before suggesting what to call it.
A capability is something a person or system can do. That could be an AI skill, an agent, a product feature, or a service you offer. The same question applies to each. Can someone roughly predict what they'll get when they choose it?
Start with what you've built
I'd start with the source, even if you already have a name you like.
What does someone give it? What work does it do? What comes back? Where does it need the person to decide or check something?
Those answers give the name something concrete to describe. They also keep the description from promising work the capability doesn't do.
Here's a made-up example. A workflow reads a proposal draft and compares it with a scope checklist. It flags missing sections. Pricing still needs your approval.
Proposal Scope Check tells me more about that work than "Proposal Genius." A description could say:
Give it your proposal draft and scope checklist. It points out missing or unclear sections for you to review. You still approve the price and confirm the claims.
Now someone can decide whether that's the help they need.
If you've already approved a name, tell the skill to keep it. It can improve the description without reopening the name, unless the name itself promises something the source doesn't support.
People and AI need different descriptions
A person needs to understand what they're choosing. An assistant needs to know when to use it.
For that same example, the assistant's instruction might be:
Use when reviewing a proposal draft against a supplied scope checklist for missing or unclear sections.
That's the routing description. It tells the assistant what kind of request should trigger the skill. The description for people explains what to give it and what they'll receive.
Naming Capabilities returns both, along with a recommended name and a short explanation of why it fits. It only adds alternative names when there's a useful tradeoff to consider.
Try it on something you're ready to share
Open the GitHub repo below and download the files. Give the complete folder to an AI assistant that can read files. Add your workflow or instructions and ask:
Read Naming Capabilities, then read this workflow. Suggest a name and write both descriptions. Make sure they describe what it does and what the person gets back. If the source leaves something unclear, ask me before making a promise.
If you have a fixed name, include it in that request. You don't need an API key or account connection to use the instructions. Installing them as a saved skill depends on your assistant.
Read the result against the source before sharing it. A clear description still needs to be true. This skill describes the work; it doesn't test the system or check whether a name is available as a trademark.
