A skill’s SKILL.md body is just instructions loaded into the conversation. If those instructions tell Claude to invoke another skill by name, Claude calls the same Skill tool a human user would - there’s no separate “call a sub-skill” primitive.
This is a context engineering choice as much as a skills choice: each Skill-tool hop loads more text into the window, so compose only the stages you need for the current task.
The hard gate
disable-model-invocation: true hides a skill from Claude’s context entirely, not just from autonomous triggering. A skill carrying that flag can’t be invoked via the Skill tool under any circumstance - even when another loaded skill’s own instructions explicitly tell Claude to call it. Removing the flag is the only way to let one skill orchestrate another automatically.
Two ways skills meet subagents
| Pattern | Who writes the task | Runs where |
|---|---|---|
Skill with context: fork + agent: | The skill’s own content becomes the subagent’s prompt | Isolated subagent - no access to the calling conversation |
Subagent with a skills field | The delegating message | The subagent’s own context, with those skills preloaded as reference material |
When to reach for orchestration
- A workflow has clean, reusable stages (fetch → draft → polish → review) that are each useful standalone.
- One entry point should run the whole pipeline without merging separate concerns into a single file.
- A stage needs a fresh context (a review pass benefits from not being close to the draft) rather than inline continuation (a rewrite pass benefits from the context already built up) - pick a subagent for the former, an inline Skill-tool call for the latter.