Skill tool redundantly invoked after slash command loads skill, fails with disable-model-invocation error

Summary

When a user triggers a skill via a slash command (e.g. /some-skill), the CLI loads the skill instructions into context. However, the system prompt instruction says:

"When users reference a slash command, invoke the relevant Skill tool BEFORE generating any other response."

This causes Claude to call the Skill tool redundantly — the skill was already loaded by the slash command path, but Claude re-invokes it via the tool. For skills that have disable-model-invocation: true set, this fails immediately with:

Skill \<name\> cannot be used with Skill tool due to disable-model-invocation

Root Cause

The system prompt instruction does not distinguish between:

1. A slash command that has already loaded the skill into context (the user-initiated path), and
2. A fresh model-initiated invocation where the skill has not yet been loaded.

In case (1), the instruction fires anyway, causing a redundant Skill(...) tool call. For skills with disable-model-invocation: true, this redundant call is rejected by the harness with the error above, even though the user explicitly initiated the slash command.

The existing safety check in the Skill tool docstring:

"If you see a <command-name> tag in the current conversation turn, the skill has ALREADY been loaded — follow the instructions directly instead of calling this tool again"

…is intended to guard against this, but in practice the model does not reliably detect the <command-name> tag before following the system prompt instruction to call the Skill tool first.

Steps to Reproduce

1. Create or install a skill that has disable-model-invocation: true in its frontmatter.
2. In a Claude Code session, type /<skill-name> as a slash command to invoke it.
3. The CLI loads the skill content into context (slash-command path).
4. Claude's system prompt instruction fires: "invoke the relevant Skill tool BEFORE generating any other response."
5. Claude calls Skill("<skill-name>").
6. The harness rejects the call: "Skill \<name\> cannot be used with Skill tool due to disable-model-invocation"
7. The skill fails to execute, even though the user explicitly invoked it.

Expected Behavior

When the user explicitly submits a slash command, the skill content is loaded into context and Claude executes it directly — without calling the Skill tool redundantly. The system prompt instruction should either:

• Not fire when a skill has already been loaded by the slash-command path in the current turn, or
• Include a clear signal in the injected context that tells the model the skill is already active and the Skill tool must not be called again.

Actual Behavior

Claude calls the Skill tool after the slash command has already loaded the skill, resulting in:

Skill <name> cannot be used with Skill tool due to disable-model-invocation

The skill does not execute. The user has to work around this by removing disable-model-invocation: true from the skill's frontmatter or manually prompting Claude to skip the tool call.

Related Issues

• #54535 — Skill tool feedback loop: getPromptForCommand body re-injected as isMeta after every model-invoked Skill call (overlapping family; different proximate cause)
• #51165 — Skills with context: fork fail with "disable-model-invocation" when invoked via Skill tool (same error surface, different trigger)
• #50075 — Skills/commands with disable-model-invocation: true are hidden from agent, blocking user-initiated slash invocation (related; user-invoked path blocked)
• #43809 — Skills with disable-model-invocation: true cannot be invoked by subagents (same flag, different invocation path)

Environment

• Affects any platform where disable-model-invocation: true skills are used with slash commands
• Reproducible with current system prompt wording (as of Claude Code v2.1.x)