[FEATURE] User-side configurable plugin namespace alias (e.g. `omcw` for `oh-my-cc-workflow`)

Preflight Checklist

• [x] I have searched existing requests and the closest prior issues are #15882, #23589, and #54487 — all of which differ from this request. See "Differentiation from prior issues" at the bottom for why this is not a duplicate.
• [x] This is a single feature request (not multiple features)

Problem Statement

Once a personal workflow is packaged as a plugin, every command it exposes is forced to use the full plugin-name namespace forever.

Concrete example: I package my workflow as a plugin called oh-my-cc-workflow containing skills start, finish, commit. After plugin-ifying, every invocation becomes:

• /oh-my-cc-workflow:start
• /oh-my-cc-workflow:finish
• /oh-my-cc-workflow:commit

This is dramatically more typing than the pre-plugin /start / /finish / /commit, and the friction actively discourages adopting the plugin system for one's own workflows — even when plugin packaging is the right architectural choice (versioning, sharing, marketplace distribution). The plugin name has to be descriptive/unique enough to be safe in a marketplace, but that same descriptiveness makes it hostile to daily typing.

Proposed Solution

Allow users to configure a local alias for an installed plugin in settings.json (user-scope or project-scope), so /<alias>:<skill> is treated as equivalent to /<plugin-name>:<skill>. The alias is purely local — it does not affect the plugin's identity in the marketplace, does not require editing the plugin's own files, and the original /<plugin-name>:<skill> continues to work.

Example config:

{
  "pluginAliases": {
    "oh-my-cc-workflow": "omcw",
    "some-other-very-long-plugin-name": "x"
  }
}

After which:

• /omcw:start ≡ /oh-my-cc-workflow:start
• /x:foo ≡ /some-other-very-long-plugin-name:foo

The alias should be free-form — anything that doesn't collide with another plugin name, alias, or standalone skill. Single letters (a, b, c) should be allowed since this is purely personal preference, not a marketplace-visible identifier.

Conflict handling:

• If alias collides with an existing plugin name, alias, or standalone skill → reject the alias at config-load time with a clear error
• Alias and original name both resolve simultaneously — no breaking change for tutorials/docs that reference the full name

Alternative Solutions

1. Wrap each plugin command in a thin standalone skill under .claude/skills/. Works but defeats the entire point of installing plugins, doubles the number of registered skills, and requires manual upkeep when the plugin adds/removes commands.

1. Rename the plugin to something short before installing (e.g. fork oh-my-cc-workflow → omcw). Loses upstream updates and breaks the plugin's identity in the marketplace.

1. Per-skill aliases inside the plugin's own SKILL.md frontmatter (this is what #54487 proposes). Doesn't work for third-party plugins you don't own — you'd have to fork and patch every plugin you install just to shorten its namespace.

1. Auto-drop the namespace when there's no collision (this is what #15882 proposed). Fragile under multi-plugin setups: invocation behavior would silently change when you install a second plugin that shares a skill name. Hard to learn / muscle-memory-hostile.

None of these alternatives let a user shorten an installed plugin's entire namespace locally, deterministically, and without touching the plugin's own files. That's the gap this FR fills.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario: I maintain a personal workflow plugin oh-my-cc-workflow with ~10 commands I use dozens of times a day across all my projects (/start, /finish, /commit, /rebase, /devtree, etc.).

1. I install the plugin from my marketplace into a fresh dev machine.
2. I add a one-line entry to ~/.claude/settings.json:

``json
{ "pluginAliases": { "oh-my-cc-workflow": "omcw" } }
``

1. From that point on I can type /omcw:start instead of /oh-my-cc-workflow:start. Original full form still works for documentation/tutorials.
2. Total typing saved per day: ~150 characters across ~30 invocations. Cognitive load reduced because the namespace is no longer a visual obstacle.
3. When I share my plugin with a teammate, they can pick their own alias (or not bother) — my plugin's marketplace identity is unaffected.

Additional Context — Differentiation from prior issues

I checked existing issues carefully and want to preempt the auto-dup bot. Here's why this is not a duplicate:

| Issue | State | What it asked for | Why this FR is different |
| ---------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| #15882 | CLOSED stale | Make plugin namespace automatically optional when there's no collision (docs claimed it was optional but implementation never matched) | Auto-drop is fragile under multi-plugin setups (behavior silently changes when a second plugin is installed). This FR proposes a deliberate, declarative, user-configured alias — collision-safe by design. |
| #23589 | CLOSED as duplicate of #15882 | "Support shorthand aliases for plugin commands" — closest in spirit to this FR | Was auto-closed by the duplicate bot pointing at #15882, but the two are actually different mechanisms. #23589 never got a standalone design discussion. This FR provides the concrete settings.json shape that #23589 lacked, and references #15882 only as a _worse_ alternative. |
| #54487 | OPEN | Per-skill aliases: array in SKILL.md frontmatter (skill-side, owned by plugin author) | Requires editing the plugin's own files — useless for installed third-party plugins unless you fork them. This FR is user-side, plugin-namespace-scoped (one alias covers all skills under that plugin), and orthogonal to #54487 — both could ship without conflict. |

Putting all three together: the gap is _user-side, plugin-namespace-scoped, declarative alias mapping_. That's what this FR proposes.