Every skill can be invoked two ways: typed as a slash command, or matched against the user's natural phrasing. Explicit always works; implicit is convenience. The good skills support both.
Chapter 2 was about writing a description that will match. This chapter is about what actually happens when a skill gets invoked — and the two distinct paths the invocation can travel down. Both lead to the same skill.
If you've ever wondered "wait, did Claude pick that skill because of my prompt, or did I have to type the slash?" — this chapter resolves it.
Every skill can be invoked two ways.
Explicit: the user types /skill-name args. Direct, intentional, deterministic. The slash is a commitment — "yes, this skill, now." It works regardless of how good or bad the description is.
Implicit: the user types something natural like "can you grab the transcript of this video?" Claude reads all available skill descriptions, picks the best match, and auto-invokes. Sometimes ambiguous. Always depends on description quality (which is exactly what Ch.2 was about).
Both paths lead to the same skill. The same SKILL.md gets read, the same workflow runs. The only difference is whether you spelled it out or Claude inferred it.
Anatomy: /skill-name [args]. That's it.
The slash prefix marks the rest of the line as a skill invocation. The name has to match the folder name. Everything after the name is args — free-form text the skill itself interprets.
Examples:
/book-builder Information Theory — args are a free-form topic./code-review high — args are a single keyword (the review level)./youtube-transcript https://youtu.be/abc123 — args are a URL./verify — no args. The skill uses sensible defaults.The slash command path always works. Even if the description is empty, even if it's ambiguous, even if there are ten other skills with overlapping triggers — typing /skill-name resolves the skill by name. No matching, no scoring, no ambiguity.
That makes explicit invocation the right path for power users, scripts, and recurring workflows where you don't want to leave anything to chance.
The user types something natural — "can you grab the transcript of this video?" — and never says the skill's name. Yet the skill fires. How?
At session start, Claude reads the description of every available skill. When you send a prompt, Claude scans those descriptions for matches against what you said. If one description fits well, the skill auto-invokes. If two fit equally, Claude usually picks the best fit silently; sometimes it asks you to disambiguate.
Three things determine whether implicit invocation works:
This is the magic path. When it works, a skill feels like Claude just knew what to do. When it doesn't work, you're stuck wondering why — which is why explicit invocation exists as a backstop.
Here's a thing that catches people out: there's no standard for args. Your skill decides what its args mean.
Common patterns:
/book-builder Information Theory. Whatever comes after the name is one big string the skill interprets as a topic./loop interval=5m task=babysit. Structured, useful when you have multiple options./deploy staging,prod. Good for "do this thing to these targets"./code-review {"effort":"high","fix":true}. Heavy but unambiguous./roman-numerals 42. The cleanest shape when one value is all you need.The convention is whatever you write in the SKILL.md body. Document it. If your skill silently expects key=value but the user types free-form, you'll both be confused.
What happens when the user's phrasing matches more than one skill description?
Usually Claude picks the best fit silently. The skill with more specific or more numerous trigger-phrase matches wins; the others lose. Done.
Sometimes the fit is genuinely close, and Claude asks: "did you mean A or B?" That's the disambiguation moment. It's a sign that your descriptions need work — two skills should never have indistinguishable triggers.
Mitigation has one ingredient: non-overlapping trigger phrases. If skill A handles X and skill B handles Y, their descriptions should share as few words as possible. If they have to share words, the descriptions should clarify the difference ("from a webpage URL" vs "from a screen capture").
A skill that handles both paths well shares a small checklist:
Get those four right and the skill works regardless of which door the user knocks on.
Most skills support both. A few have a natural lean.
Lean explicit when the skill is a power-user tool you'll always type by name. A deploy command. A code review. A specific build task. Users who reach for it already know its name — invest less in trigger phrases, more in args.
Lean implicit when the skill is a discovery-friendly utility — something a casual user might benefit from but won't know exists. A transcript fetcher. A converter. A formatter. Invest heavily in trigger phrases so it surfaces naturally.
The two example SKILL.md files below show the two postures side by side.