[MODEL] Skill auto-loading via slash command is invisible to user — creates trust gap

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

I asked Claude to use /cmux and /exp skills when setting up workspaces and branches. The exact phrasing was: "also we mean using /cmux skill and /exp skill when we talk about workspaces and branches."

Later, I typed /introspect at the start of a message to invoke that skill.

What Claude Actually Did

For /cmux and /exp: Claude did not invoke the Skill tool. It ran the CLI commands directly (cmux new-workspace, exp new) from memorized examples in CLAUDE.md and memory files, getting the arguments wrong — it sent terminal messages to the wrong workspace.

For /introspect: The system auto-loaded the skill content (via <command-name> tag injection) because it was at the start of my message. Claude then executed the skill framework directly — no Skill tool call was made. From my terminal, I saw no indication the skill had been loaded. I couldn't tell if Claude was following the skill instructions or improvising.

When I asked Claude to "call /introspect," it said it already had the content. But I had no way to verify this from the terminal output.

Expected Behavior

1. Skill invocation should always be visible to the user — either through a Skill tool call or a clear system indicator when auto-loading occurs
2. When I mention /skill-name in natural language, Claude should invoke the Skill tool (visible action), not guess from memorized CLI patterns
3. The user should never be in a position where they can't tell if a skill was loaded or not

Root Causes Identified

Two compounding issues:

1. Silent auto-loading: When /skill appears at the start of a user message, the system injects skill content via <command-name> tags. Claude's system prompt then says: "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." This means no Skill tool call is made — the user sees nothing.

1. Positional sensitivity (undocumented): /skill at the start of a prompt triggers auto-loading. /skill mid-sentence does not. This means the same syntax (/skillname) behaves completely differently depending on where in the message it appears. We confirmed this through testing in the session.

Contributing factor: My CLAUDE.md contained CLI usage examples for exp and cmux (e.g., cmux new-workspace --cwd ~/Code/project --command "claude"), which gave Claude enough confidence to skip skill invocation entirely and run commands from memory — incorrectly.

Files Affected

No files were incorrectly modified, but commands were sent to the wrong terminal workspace due to Claude using memorized CLI patterns instead of loading the skill with correct usage patterns.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Auto-load invisibility:

1. Create a skill at ~/.claude/skills/my-skill/SKILL.md with distinctive content
2. Type /my-skill do something as your full message
3. Observe: no Skill tool call in terminal, but Claude follows the skill instructions
4. Ask Claude: "did you load the skill?" — Claude says yes, but you have no evidence

Positional inconsistency:

1. Same skill as above
2. Type: "please use /my-skill for this task" (mid-sentence reference)
3. Observe: skill is NOT auto-loaded — Claude must use the Skill tool (if it does at all)

Skill bypass via CLAUDE.md:

1. Document CLI usage examples in CLAUDE.md for a tool that also has a skill
2. Ask Claude to "use /that-skill"
3. Claude may run CLI commands from CLAUDE.md instead of invoking the skill

Claude Model

Opus

Relevant Conversation

User: "also we mean using /cmux skill and /exp skill when we talk about workspaces and branches"
Claude: [runs `exp new` and `cmux new-workspace` directly as Bash commands without invoking skills]
Claude: [sends `cmux send` to wrong workspace due to incorrect args]

User: "did you invoke /cmux and /exp like I asked?"
Claude: "You're right — I did not invoke the /cmux or /exp skills."

--- later ---

User: [types /introspect at start of message]
System: [auto-loads skill via <command-name> tag — invisible to user]
Claude: [starts executing skill framework with no visible tool call]

User: "call /introspect (you just did it again)"
Claude: [this time uses Skill tool — visible in terminal]

Impact

Medium - Extra work to undo changes

The incorrect cmux send commands went to the wrong workspace, and significant time was spent debugging whether skills were actually loaded. The trust gap — not knowing if Claude has the skill content — is the real cost.

Claude Code Version

2.1.87 (Claude Code)

Platform

Anthropic API

Additional Context

Related issues:

• #39390 — Explicit /skill-name invocation overridden by trigger-keyword matching
• #14851 — Commands loaded into context without being invoked
• #16900 — Clarify relationship between skills and slash commands
• #17578 — Inconsistency in docs about skills/commands merger

Suggestion: The simplest fix would be to always show a visible indicator when a skill is loaded, whether by the system or by the Skill tool. The current behavior where auto-loading is invisible creates an inherent trust problem — the user can never verify what Claude is working with.