[BUG] Two plugins can claim the same skill name and both install silently — and it ships in a real config today

Summary

Plugin skills share a single flat namespace across every installed plugin and every marketplace. Two plugins can claim the same skill name: and both install with no warning at any point — not at marketplace add, not at plugin install, not in plugin details.

This is not theoretical. It ships today in a working configuration on my machine (details below).

Prior reports of the underlying namespacing gap — #50486, #43695, #22517, #22063 — are all closed as stale. They were auto-closed for inactivity rather than resolved, so I'm filing fresh rather than commenting on closed threads. This one adds two things they don't have: a minimal repro, and a live instance.

Version: Claude Code 2.1.228, Linux.

Repro

Two throwaway marketplaces, each with one plugin, each shipping a skill named doctor:

mkt-alpha/.claude-plugin/marketplace.json      name: mkt-alpha, plugins: [alpha]
mkt-alpha/plugins/alpha/.claude-plugin/plugin.json
mkt-alpha/plugins/alpha/skills/doctor/SKILL.md     -> name: doctor

mkt-beta/...                                       -> name: doctor  (plugin: beta)

export CLAUDE_CONFIG_DIR=$(mktemp -d)
claude plugin marketplace add ./mkt-alpha && claude plugin install alpha@mkt-alpha
claude plugin marketplace add ./mkt-beta  && claude plugin install beta@mkt-beta
claude plugin details alpha
claude plugin details beta

Observed

Both install successfully. Both report the same skill:

$ claude plugin details alpha
Component inventory
  Skills (1)  doctor
  ...
$ claude plugin details beta
Component inventory
  Skills (1)  doctor
  ...

No warning, no error, no mention that the name is contended. Nothing in the CLI surfaces that a second plugin has claimed a name the first already holds.

Expected

At minimum, a warning at install time naming the other claimant. Better, the same treatment commands already get: namespace the skill as plugin:skill, so alpha:doctor and beta:doctor can coexist — which is what #50486 asked for.

It already ships in a real config

The reason I care isn't the synthetic case. On this machine, two enabled plugins from different marketplaces both claim doctor:

• bios-implant (public marketplace) — skills/doctor/SKILL.md, name: doctor
• an internal plugin from a private org marketplace — skills/doctor.md, name: doctor

Both are true in enabledPlugins in ~/.claude/settings.json. Neither install warned. Nobody chose this; it accumulated.

Note the second one ships its skill as a flat file (skills/doctor.md) rather than a directory — which is why my own first audit of the machine missed it: I enumerated skill directories. Worth knowing for anyone else trying to audit their own install for collisions; the two layouts have to be checked separately.

Why generic names are the norm, not carelessness

The plugin I maintain ships boot, connect, doctor, install. Those were reasonable when written — Claude Code namespaces plugin skills as plugin:skill in its own UI, so they read as scoped. The flat namespace is where they stop being scoped, and there is no signal at authoring time that a name is contended, nor any way to require the qualified form.

The Desktop dimension the earlier issues don't cover

The prior reports are all about Claude Code. The same plugin in Claude Desktop shows its skills with no plugin prefix at all — while its MCP servers stay namespaced in the same UI (bios-implant:implant-local under Connectors). Only skills are flattened, and I can't find a stated reason for the asymmetry.

(That Desktop observation is from a colleague's side-by-side walkthrough of both hosts, not from my own screen — flagging the provenance. Everything else above I ran myself.)

What would help, in order

1. A warning at install when a skill name is already claimed, naming both plugins. Cheap, and it turns a silent condition into a visible one.
2. Namespace skills like commands (plugin:skill), in both Claude Code and Desktop — #50486's ask.
3. An opt-in for authors to require the qualified form — #43695's ask.

Happy to supply the repro tree if it's useful.