[FEATURE] Configurable slash command trigger prefix

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The "/" prefix used to invoke slash commands is hardcoded, with no way to customize it. Unlike keyboard shortcuts, which can be remapped, there's no equivalent "keymap" concept for command triggers — every user is stuck with "/", regardless of personal preference or habits carried over from other tools.

Proposed Solution

I'd like to see the trigger symbol (the interface layer) separated from the command content (the data layer):

• Command content (.claude/commands/*.md) would stay exactly as it is today: a name-to-content registry that's committed to the project and shared with everyone who works in that repo.
• The trigger symbol (e.g., "/", or an alternative like "$") would become a user-level setting (e.g., in ~/.claude/settings.json) rather than something stored in the project's shared config.

Each user's client would parse their own configured symbol, extract the command name, and look it up in the same shared registry. The command files themselves wouldn't need to know or care which symbol was used to invoke them.

This would only add an optional override — "/" would stay the default for anyone who doesn't configure anything, so existing behavior and documentation would be unaffected.

Alternative Solutions

I checked whether the existing keybindings system (~/.claude/keybindings.json) already covers this, but it doesn't: keybindings remap physical key combinations in the terminal UI (like Ctrl+S), not the text-based "/" prefix parsed from chat input. Since these are two different layers, there's currently no workaround beyond accepting "/" as-is.

Priority

Low - Nice to have

Feature Category

Configuration and settings

Use Case Example

1. I'm building a personal Claude Code framework with reusable commands under .claude/commands/.
2. I'd prefer to invoke commands with a different symbol (e.g., "$") that better fits my own habits or naming conventions.
3. With this feature, I could set my preferred trigger symbol once, in my user-level settings.
4. My command content would stay fully portable: if I share this repo with a collaborator who still uses "/", their client resolves the same commands using their own configured symbol — no conflicts, no per-repo lock-in.

Additional Context

This mirrors how IDEs separate "keymap profiles" (e.g., a VS Code keymap vs. an IntelliJ keymap) from the actions they trigger — the action is shared, while the binding is a personal preference layered on top. Keeping the trigger-symbol preference at the user level, rather than the project level, is what preserves the portability of shared command files across users with different preferences.