[BUG] Slash command name collision: plugin skill shadows built-in /release-notes

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

When a plugin skill and a built-in slash command share the same name (e.g. /release-notes), the autocomplete menu correctly shows both entries, but
pressing Enter on either entry dispatches to the plugin skill. There is no way for the user to reach the built-in command while the plugin is
installed.

## Environment

• Claude Code:  2.1.150
• OS: macOS
• Shell: zsh
• Plugin installed: pm-skills (provides pm-execution:release-notes, registered as /release-notes)

## Impact

• Users cannot view Claude Code's own changelog via the documented /release-notes command once any plugin claims that name.
• The only workaround is to disable or uninstall the conflicting plugin.
• The autocomplete UI implies user choice, but the resolver ignores the selected row and dispatches by name.

## Suggested fixes

1. Respect the menu selection. Dispatch the exact entry the user highlighted, not a re-lookup by name.
2. Prefer built-ins on name collision. Built-in commands win when a plugin skill registers a colliding name; surface a warning to the plugin

author.

1. Force plugin namespacing in the slash menu. Show plugin skills as /pm-execution:release-notes (their fully-qualified ID) so collisions are impossible at the UI layer.
2. Detect collisions at install/load time and prompt the user to choose, or auto-rename one with a clear notice.

Option 1 is the least disruptive UX fix; option 3 is the most robust long-term.

What Should Happen?

### Expected
The built-in release notes viewer opens.

### Actual
The plugin skill pm-execution:release-notes is invoked instead, regardless of which entry was highlighted in the menu.

Error Messages/Logs

Steps to Reproduce

## Steps to reproduce

1. Install a plugin that registers a skill named release-notes. Example: the pm-skills plugin's pm-execution:release-notes.
2. In the Claude Code prompt, type /release.
3. Observe the autocomplete list shows two entries with identical names:

• /release-notes — (pm-execution) Generate user-facing release notes …
• /release-notes — View release notes (built-in)

1. Use the arrow keys to highlight the second entry (the built-in View release notes) and press Enter.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.150

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Screenshot

<img width="1204" height="96" alt="Image" src="https://github.com/user-attachments/assets/ec55c232-d0da-416d-a37c-d37f763680e6" />

Related issues

• #54829 (open) — Plugin slash-command autocomplete drops namespace prefix on accept. Related but distinct: that issue is about a namespaced

plugin entry (/shared:publish-package) being inserted as the unprefixed form. Here, both colliding entries are unprefixed /release-notes to begin
with, and the bug is that menu selection has no effect on dispatch.

• #26906 (closed, stale) — Fully-qualified plugin command namespace ignored — local skill executed instead. Related but distinct: that report

covers the user explicitly typing the fully-qualified /plugin:command form and still being misrouted. This issue is about a same-name collision
between a built-in command and a plugin skill where no fully-qualified form is available for the built-in.

• #50486 (open, stale) — feat(plugins): namespace plugin skills with plugin name prefix like commands. Enhancement proposal that would prevent

collisions at the UI layer (matches suggested fix #3 above), but is not a bug report for this specific dispatch behavior.

• #41088 (open, stale) — Allow configuring slash command priority/ordering. Enhancement proposal covering the general collision-resolution

policy (matches suggested fix #2 above); does not describe this specific built-in-vs-plugin scenario.