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. Per the docs, a skill carrying that flag stays out of context until you invoke it with /name. The docs don’t address skill-to-skill calls, so assume the flag also blocks a call that another loaded skill’s instructions ask Claude to make, and test it before you build on that path. 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.
Composition is the second question. The first is which recurring prompts are worth codifying as skills at all - covered in The vibe-coding field manual.