TL;DR: Typing
/release-checkand having Claude selectrelease-checkare different entry points. Both expand a Skill from candidate metadata into instructions for the current task. The immediate result is not “the release is complete,” but “this way of working is now in play.”disable-model-invocationanduser-invocabledecide who can open that door; neither guarantees every step afterward will run.
Part 3: From a Directory to Claude's Candidate List explained how scope, directories, namespaces, and paths shape the candidate capability list.
Suppose that list includes:
release-check · Check whether a code version is ready to release
When does that one-line description become instructions that affect the task? There are two entry points:
Direct user invocation
/release-check
Claude's own selection
“Can we ship this version?”
↓ description matches
choose release-check
Both are called “invoking a Skill,” but their initiators, control, and best use cases differ.
Manual invocation: the user selects the capability
When the user starts a message with:
/release-check
they are not merely mentioning a filename in chat. They are explicitly asking Claude Code to load and use this Skill. The user has made the capability-selection decision; Claude does not need to guess among dozens of descriptions.
Manual invocation is particularly useful when:
- The user controls the timing: Only they know that the project has formally entered the release stage.
- Actions may have side effects: Deployment, commits, messages, and updates to external systems.
- The workflow is expensive: Deep reviews, full verification, or batch processing should not start casually.
The user can include an argument:
/release-check v2.4.0
At invocation, Claude Code renders the argument into the Skill's instructions. Claude receives a task about v2.4.0, not merely a generic request to “use release-check.” We will examine argument substitution and dynamic context in Part 5.
Manual invocation controls the entry point. It does not turn a Skill into a traditional CLI command. After loading, Claude still interprets the instructions, assesses the environment, and uses tools to make progress.
Model invocation: Claude selects from the candidate list
The user may not know the Skill's name:
Can you check whether this version is ready to ship and identify blockers?
If the release-check description matches, Claude can select the Skill on its own. It routes from user intent to a candidate name and description, then asks Claude Code to load the full Skill.
This resembles ordinary tool selection: Claude sees a capability description, judges relevance, and makes a structured call. The distinction is what comes back. A normal tool enters its executor immediately; a Skill first supplies instructions.
Model invocation works well when users describe goals rather than memorizing internal names; when domain knowledge should naturally participate in related tasks; when several Skills may be combined; and when no high-risk timing decision must belong to the user.
Automatic selection is what lifts a Skill beyond a saved command into a capability Claude can discover and choose.
Two entrances, one convergence point
The flows can be simplified like this:
User: /release-check v2.4.0
↘
Find Skill definition
Render arguments and dynamic context
Load instructions in the appropriate context
Claude orchestrates existing tools
↗
Claude: Skill(release-check)
Before convergence, the selection differs: the user chooses in one path; the model chooses based on the request and description in the other. Afterward, both need to find SKILL.md, render parameters, place the resulting instructions in the right context, and continue the workflow.
“The user can type /name” and “Claude can use it proactively” are therefore separate capabilities, not two expressions of one switch.
What has a Skill call actually accomplished?
Compare:
Read(file)
→ returns file content
Skill(release-check)
→ loads release-check instructions
For Read, the tool result is the requested observation. For Skill, the immediate result is new operating guidance. The release check itself is still ahead. Claude may next read Git status, run tests, inspect the version file and changelog, and produce a risk report.
A normal tool call observes or changes external state. A Skill call changes how the agent will work next.
A Skill can also run inside a forked subagent and return a completed result. That changes the execution context, not the fact that instructions drive the work.
The slash is a shared interface, not one execution model
Claude Code presents /compact, /release-check, and bundled Skills with similar slash names. It is tempting to treat them all as Markdown prompts. At least three categories matter:
| Category | Core content | What invocation does |
|---|---|---|
| Built-in command | Product logic | Runs a Claude Code feature directly |
| Bundled Skill | Anthropic-provided, prompt-based workflow | Loads instructions and orchestrates tools |
| Custom Skill | User-, project-, or plugin-provided capability package | Loads custom instructions and resources |
A built-in command may change a mode, manage a session, or open product UI without handing a method of work to the model. Bundled and custom Skills primarily guide Claude through instructions. The interface is shared; the semantics are not.
The useful dividing line is whether /name triggers fixed product behavior or loads instructions for Claude to carry out with tools.
Why old custom commands still work
An older custom command is also Markdown expanded through /name. Claude Code folded prompt-based commands into its Skill model while preserving the old .claude/commands/ layout.
The shared path is: select a name, expand prompt-based content, and let Claude continue. A full Skill adds supporting files, discovery, invocation control, and execution options. Migration is thus not “slash commands no longer work”; it is “a single-file prompt can grow into a capability package.”
If a Skill and an older command share a name, the Skill takes precedence. Keeping two same-named definitions after migration makes it harder to tell which one runs; removing the duplicate entry is clearer.
Who can invoke it? Two independent switches
By default, both the user and Claude can invoke a Skill. The Claude Code documentation distinguishes two frontmatter fields:
| Configuration | User can invoke | Claude can invoke | Typical use |
|---|---|---|---|
| Default | Yes | Yes | Ordinary reusable workflow |
disable-model-invocation: true |
Yes | No, not on its own | User-timed deployment or commit |
user-invocable: false |
No | Yes | Background domain knowledge |
disable-model-invocation asks whether Claude may choose the Skill proactively. user-invocable asks whether it should be available as a user command.
User-only invocation
---
name: deploy-production
description: Deploy the current release to production
disable-model-invocation: true
---
The Skill may contain a complete deployment checklist, but Claude cannot activate it simply because the code looks ready. The user must invoke it explicitly.
Claude-only invocation
---
name: legacy-system-context
description: Domain constraints for the old order system; use when working on legacy order code
user-invocable: false
---
This is closer to on-demand reference material. The user need not type a command with no action semantics; Claude can load it when the task calls for it.
Invocation direction should reflect the capability's nature rather than being left at the default without thought.
Why user-only Skills reduce discovery cost
For Claude to invoke a Skill on its own, its name and description must be in candidate context. If the Skill explicitly prohibits model invocation, showing that description to Claude continuously serves no matching purpose.
Claude Code connects invocation control to exposure: descriptions of model-invocable Skills remain available for selection, while disable-model-invocation: true keeps the description out of Claude's context until the user calls the Skill. user-invocable: false hides the user command, but Claude still needs its description to choose it.
This is not only permission semantics. It also affects the fixed metadata cost in progressive disclosure's first layer.
Invocation is not blanket permission
Typing /release-check authorizes using that checking workflow. It does not automatically authorize arbitrary shell commands, editing every file, deploying to production, bypassing workspace trust, or escaping a sandbox.
A Skill can declare pre-approved tools, and Claude Code also has permission rules. Those are separate governance layers. Invocation answers who may start the capability, not what unrestricted powers it gets afterward.
Nor is disable-model-invocation a complete security boundary. It blocks normal proactive Skill invocation. The file, bundled scripts, tools, and external systems still need appropriate permissions and isolation.
Manual choice is not deterministic execution
Suppose a Skill says:
1. Run the tests.
2. Check the version.
3. Produce a report.
Even when the user explicitly types /release-check, a model interprets those instructions. The test command might be missing, context may conflict, or a tool call may fail. Claude has to decide how to recover.
Manual invocation gives a deterministic choice of workflow, not a deterministic execution trace. If a step must happen mechanically and without exception, consider a script, an event-triggered Hook, permission rules that block forbidden actions, or CI and external verification. A Skill guides behavior; it should not carry enforcement alone.
Skills can be composed
Invocation does not put the session in an exclusive mode. One task might need:
release-check
+ security-review
+ changelog-style
Their instructions can jointly affect the work. That enables composition—and conflict. Do two Skills demand different output formats or tool orders? Do both claim ownership of the whole workflow? Is one only a reference while another leads the task?
Composition is not merely adding more prompts. Clear capability boundaries let instructions cooperate. If every Skill claims to control the entire task, simultaneous activation becomes competition.
The two invocation switches decide who starts the Skill. They do not decide whether it runs inline in the main conversation or in a subagent; that is an execution-context decision for Part 6.
The essential point: Skill invocation is not a saved macro. User invocation supplies an explicit choice; model invocation supplies automatic routing. Both bring on-demand operating knowledge to Claude, which then uses tools to turn the method into action.
Up next
The Skill has been selected, but the file on disk is not necessarily what Claude will see. $ARGUMENTS, positional parameters, Skill-directory variables, and dynamic shell output can alter the prompt before it enters context. Part 5 examines that rendering step—and why a command Claude has not yet read may already have run.
Top comments (0)