How to properly activate Claude Code skills

The most common complaint about skills is not installation — installs take seconds — it is that an installed skill silently never fires. Having just installed 21 skills across 8 packages in one session, here is how activation actually works and the levers that reliably fix it.

How activation works (30 seconds)

Installed skills are presented to Claude as a list of names and descriptions; the model decides to load one when your request matches what the description promises. That mechanism has two consequences. First, the description is the trigger surface — not the skill body, which only loads after the match. Second, activation is probabilistic: phrasing that matches the description fires; phrasing that doesn't, doesn't.

Lever 1: invoke explicitly when it matters

The zero-ambiguity path: name it. "Use the kill-ai-slop skill to review this page" activates regardless of description quality. If a skill run is load-bearing — a review gate, a deploy step — say the name and remove luck from the equation entirely.

Lever 2: write (or read) the description like the authors of the good ones do

The best-engineered skills in our tested batch treat the description as a trigger list, not a summary. kill-ai-slop's description enumerates the phrases users actually say: "use when the user asks to 'kill AI slop', 'de-slop', 'remove the AI look', 'make this not look AI-generated'…" CodeDrobe's description names every app, file format and verb it should respond to. That is the pattern to copy in your own skills — and when an installed skill won't auto-fire, open its SKILL.md and check whether your phrasing appears anywhere in its description; if not, either rephrase your request or edit the description.

Lever 3: check the skill actually landed where your session looks

Skills live at project level (.claude/skills/) or user level (~/.claude/skills/). The installer defaults to project scope in a project; a skill installed in another repo does not exist here. npx skills list shows what is installed where — thirty seconds of checking beats an hour of prompt archaeology.

Lever 4: fewer, better skills

Every installed skill adds a description competing for the model's attention. Our test project ended the session with 21 skills installed, and the practical difference was visible: generic requests match more descriptions, and near-duplicate skills (we had three anti-slop variants at one point) can shadow each other. Keep the installed set down to what you use; uninstalling is npx skills remove.

Lever 5: for must-run skills, use a hook

For teams that need a skill to run on every session regardless of phrasing, the community pattern is a Claude Code hook that injects the requirement mechanically. It trades flexibility for certainty — right for compliance-style skills, overkill for everything else. This is the one lever we have not exercised in our own test batch yet; it goes into the retest cycle.

FAQ

Do I need to restart Claude Code after installing a skill?

Start a fresh session in the project after installing — skills are read at session start, so a mid-session install may not be visible until then.

Why does the same request fire the skill some days and not others?

Because matching is a judgment call by the model, phrasing sensitivity is real. If consistency matters, Lever 1 (explicit naming) is the answer — it is not a workaround, it is the designed escape hatch.