The first rule of skill selection: match on capability, not on name. A skill called “SEO Writer Pro” tells you nothing until you know which capability it executes, which input it accepts, and what it actually delivers.
Check the capability first
Every skill entry lists the capability or capabilities it executes. Start your selection from the capability nodes in the relevant scenario tree, then look for skills that claim exactly those capabilities. If a skill does not state its capability, treat it as unvetted regardless of how good the description sounds.
Match granularity to the task
Granularity is the size of the job the skill promises:
- Atomic skills do one bounded action. Use them when the task is a single step inside a bigger flow.
- Composite skills run several actions toward a stage result. Use them when a step has internal structure.
- Delivery skills run from goal to finished deliverable. Use them only when you want the whole loop owned by one skill.
The common mistake is reaching for a delivery skill when an atomic one suffices. Prefer the smallest skill that honestly covers the task. Smaller skills are easier to test, easier to replace, and easier to combine.
Read the contracts
Before you pick a skill, check its input and output lists. Does it accept the material you actually have? Does it produce the deliverable you actually need? A skill that needs a database when you have a folder of markdown files is not a fit, no matter how well reviewed it is.
Weigh verification state
Verification status answers a specific question: has anyone independently run this skill and recorded the result? “Unverified” is not “bad”. It means the evidence does not exist yet. For a low-risk step, unverified is fine. For a step that gates a publish or a deploy, prefer tested skills, or budget time to test the skill yourself.
Keep a fallback chain
Never commit to a single skill without naming a fallback. Skills break, environments change, and models update. Before you start, decide what you will do if the chosen skill fails: which alternative executes the same capability, and which replacement component you can swap in. The fallback chain is what turns a skill selection into a reliable workflow.
The selection order
- Identify the capability from the scenario tree.
- Filter skills by that capability.
- Match granularity to the task size.
- Check the input and output contracts against your material.
- Compare verification state and pick the best evidence.
- Name a fallback before you start.
The whole process takes minutes and it converts skill selection from a popularity contest into an engineering decision.