[MODEL] Explicit /skill-name invocation overridden by trigger-keyword matching on arguments

Resolved 💬 4 comments Opened Mar 26, 2026 by philmcardle Closed Apr 25, 2026

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

/resolve [screenshot] Always allow this permission prompt.

I explicitly invoked the /resolve skill (a plugin-provided issue resolver) with a screenshot and description as arguments.

What Claude Actually Did

  1. Ignored the explicit /resolve skill invocation
  2. Evaluated the argument text ("Always allow this permission prompt") against other skill trigger descriptions
  3. Concluded "This isn't an issue to resolve — it's a permission configuration request"
  4. Invoked Skill(update-config) instead — a completely different skill
  5. Proceeded to modify ~/.claude/settings.json (adding a Write permission glob)

Expected Behavior

When a user types /<skill-name> <args>, the named skill should always be invoked. The arguments are parameters to that skill, not a signal to re-classify intent and route elsewhere.

Expected: /resolve loads and begins its issue resolution workflow, treating the screenshot and text as the issue description.

Files Affected

Modified:
  - ~/.claude/settings.json (added a Write permission glob — not requested, resulted from wrong skill being invoked)

No files should have been modified — the /resolve skill's first phase is planning, not file edits.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

  1. Install a plugin with two skills: one invoked by slash command (e.g. /resolve), another with trigger keywords matching common words like "allow", "permission", "always" (e.g. update-config)
  2. Invoke: /resolve [screenshot] Always allow this permission prompt.
  3. Claude ignores the explicit /resolve invocation and routes to the other skill based on argument text matching its triggers

Claude Model

Opus

Relevant Conversation

User: /resolve [Image #1] Always allow this permission prompt.

Claude: "This isn't an issue to resolve — it's a permission configuration request. The screenshot shows a Write permission prompt for .claude/ship-session-*.json files. Let me route this to the right skill."

Claude then invoked Skill(update-config) and modified ~/.claude/settings.json.

The user explicitly typed /resolve — a registered skill — but Claude re-interpreted the intent from the argument text and routed to a different skill entirely.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.84

Platform

Anthropic API

Additional Context

The plugin system allows skills to declare trigger descriptions (e.g. update-config triggers on "allow X", "add permission", "always allow"). When a user explicitly invokes a different skill via /skill-name, the argument text should not be evaluated against other skills' triggers. The explicit slash command should be a hard routing decision.

This is a plugin skill routing issue, not specific to any language or project type. Observed with a custom plugin (claude-config) that registers ~15 skills.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗