Claude Code activates skills in three ways. If a skill "doesn't work", it's almost always an activation problem, not a broken skill.
The three activation paths
1. Automatic. Claude reads every installed skill's description and loads the skill when your request matches. Ask "review this code" and a code-review skill with a matching description activates on its own.
2. Explicit slash command. Type / in the prompt to list installed skills, then invoke one by name. This forces activation regardless of matching.
3. By mention. Naming the skill in your request ("use the frontend-design skill") reliably pulls it in.
When a skill won't trigger — the checklist
Is it actually installed? Run ls .claude/skills/ (project) and ls ~/.claude/skills/ (global). The skills CLI installs into the current directory's project scope by default.Was the session restarted? Skills are read at session start. Installing mid-session → restart Claude Code (or start a new conversation).Read the description. Automatic activation matches YOUR words against the skill's description. A skill described as "systematic debugging" won't fire on "why is this broken?" — either rephrase, or invoke it explicitly with /.Check for description collisions. Two skills with near-identical descriptions compete; Claude may pick the other one. Prune or explicitly invoke.Project vs global conflict. A project-level skill with the same name shadows the global one.Keep activation sharp
Fewer, sharper skills beat many vague ones — every description competes for the model's attention on every request.When you write your own skill, write the description as the *user's request*, not the skill's résumé: "Use when asked to review a pull request" beats "A comprehensive code quality tool".Ready-to-install skills with proven activation patterns: browse the most-installed skills — install counts come straight from the skills CLI.