Uninstalled marketplace plugin silently claims a slash-command name and breaks a local skill (reported as an arity error)

Summary

An uninstalled marketplace plugin silently claims a slash-command name and breaks a local user skill. The failure surfaces as an arity error, which points at the wrong subsystem entirely.

What happened

A local user skill at ~/.claude/skills/rc/SKILL.md stopped receiving arguments. /rc <args> behaved as though no arguments were passed, and the error presented was an arity error — so we spent a long time auditing the skill's own frontmatter and argument handling.

The actual cause: a catalog entry named rc in plugin-catalog-cache.json claims the /rc command and shadows the local skill.

The important part: that plugin is not installed and is not in enabledPlugins. Its mere presence in the cached catalog was enough to take the name. Nothing in the UI indicates the local skill has been shadowed.

How we proved it

Eliminated, in order:

• our own edits — frontmatter was byte-identical across 8 commits
• all-skills-broken — other local skills accepted arguments normally
• argument-hint length — shortened 271 → 97 chars, no change
• duplicate skills on disk — only one skill declared name: rc
• the tool the skill invokes

Decisive test: a byte-identical clone of the skill under a different name (rctest) accepted arguments correctly, while rc did not. Same contents, same frontmatter — only the name differs.

Repro

1. Have a catalog entry named X present in plugin-catalog-cache.json, uninstalled and not enabled.
2. Create a local user skill ~/.claude/skills/X/SKILL.md with name: X that takes $ARGUMENTS.
3. Invoke /X <args> — the arguments never arrive, and the failure is reported as an arity error.
4. Copy the same skill to ~/.claude/skills/Y/, changing only name:. /Y <args> works.

Why this is worth fixing

• The error names the wrong subsystem, so the diagnostic path is long and misleading.
• An uninstalled plugin should not be able to reserve a command name. If catalog presence alone reserves names, the catalog becomes a silent global namespace users can neither see nor control.
• There were ~294 names in the cached catalog on this machine. Any of them can collide with a user's local skill at any time, without the user installing anything.

Suggested fixes, cheapest first

1. Report a name collision as a name collision, naming the shadowing plugin. This alone removes most of the cost.
2. Give locally-defined user skills precedence over uninstalled catalog entries.
3. Only allow installed/enabled plugins to reserve command names.

Workaround

Rename the local skill. We renamed /rc to /ss, after first verifying that ss was absent from the catalog.