Add `chat:openCommandPicker` keybinding — slash-command picker cannot be opened mid-message

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 slash-command picker only opens when / is the first character of the message.
Once I have typed a single word, it can no longer be opened at all.

This makes skill discovery impossible at scale. I have 1091 skills installed. The
picker is the only way to browse them — there is no other surface that lists what is
available while I am composing. So in practice, any skill whose exact name I have not
memorised is unreachable the moment I start writing. I cannot realistically memorise
1091 names.

The failure mode is specific and repeats daily: I write out a request, realise
partway through that a particular skill applies, and have no way to find it. My
options are to delete what I wrote and start over with /, or to abandon the skill
and write the request without it. I usually do the latter, which means most of my
library goes unused not because it is unhelpful but because it is invisible.

This is worse in the Claude Code Desktop app, where there is no "browse skills"
affordance in the input field at all (#40413) — the / picker is the only discovery
path that exists.

To be clear about scope: invoking a command works fine. Typing the full /name
resolves correctly. The gap is purely discovery — knowing what is there.

Proposed Solution

Add a chat:openCommandPicker keybinding action that opens the picker at the current
cursor position, regardless of where the cursor is in the message.

{ "context": "Chat", "bindings": { "ctrl+/": "chat:openCommandPicker" } }

Suggested defaults: Cmd+/ on macOS, Ctrl+/ on Windows and Linux.

This deliberately avoids the objection that closed the previous requests. #55173 was
declined as "not planned" because auto-triggering on a mid-line / would produce
false positives on file paths such as /usr/local/bin or ./config/routes.rb. That
reasoning is sound and I am not asking for it to be overruled.

An explicit keypress has zero false-positive risk. A file path cannot trigger a key
the user did not press. It solves the whole use case — browse, select, insert at
cursor — without altering typing behavior for anyone.

It is also purely additive. The autocomplete keybinding context today exposes only
accept, dismiss, previous, and next; there is no action that opens the picker.
Adding one changes no defaults and breaks nothing for users who never bind it.

This exact solution was already proposed in #29752, where it was the primary
recommendation, but that issue was closed as a duplicate and the keybinding was never
evaluated on its own merits — it was folded in with the mid-line trigger request and
declined alongside it.

Alternative Solutions

lternatives I have already tried, and why they fall short:

1. Type the command first, then the request (/sk skill-a skill-b <request>).

Works, but inverts how I think — I usually only realise which skill applies after
describing the problem. It also allows one command per message.

1. Naming skills in prose ("use the mssql and sql-pro skills"). Reliable, but

requires knowing the name already, which is the exact problem.

1. A local HTML index of my own skills with live search, kept open beside the app,

copying names to the clipboard. This is what I currently do. That I had to build a
separate application to browse my own skills is itself the strongest evidence that
the built-in discovery path does not scale.

Alternative implementations that would also solve it, if a keybinding is not viable:

• An opt-in setting, off by default: { "slashCommandPickerMidLine": true }
• Trigger only on whitespace + /, which excludes ./, ../, and mid-token paths
• A searchable skill picker UI reachable from the input field (as raised in #40413)

Any of these would work. The keybinding is simply the lowest-risk of the four.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Concrete scenario from today:

1. I am investigating why a SQL report runs slowly, in the Claude Code Desktop app.
2. I type: "Check why the Holon employee query is slow — it scans 567k rows and the

phone-matching join has no index."

1. Mid-sentence I realise I want the mssql and sql-pro skills loaded for this.
2. I press Ctrl+/. The picker opens at the cursor. I type "sql", see sql-pro,

sql-queries, sql-to-business-logic, mssql, postgres, and pick the two I want.

1. They are inserted at the cursor. I finish the sentence and send.

What happens today at step 4: nothing. / inserts a literal slash. To use those
skills I must delete the whole message and retype it starting with the command, or
give up and send it without them. I almost always give up — which means I paid for
skill infrastructure I cannot reach.

Additional Context

Environment:* Claude Code Desktop app, Windows 11, v2.1.251, 1091 skills in
~/.claude/skills/, 3 custom commands in ~/.claude/commands/.

Prior requests, all closed without the keybinding being evaluated:

• #13073 — use slash commands after the first character
• #29752 — mid-line trigger and keybinding; closed as duplicate. Confirmed there

that chat:openCommandPicker does not currently exist.

• #40413 — Desktop app has no skill browsing in the input field; closed as duplicate
• #44488 — trigger anywhere in the prompt; closed as duplicate
• #55173 — mid-prompt autocomplete; closed as not planned, now locked to

collaborators, which is why I am opening a new issue rather than commenting there.

Prior art: Cursor's Composer opens its / picker anywhere in the input. VS Code,
Slack, Notion, and Linear all expose a command palette on an explicit keybinding
rather than relying on a leading character.

Why I think this is worth revisiting despite #55173: that issue asked for
automatic mid-line triggering, and was declined for a good reason. This asks for an
explicit, opt-in, user-initiated action that carries none of that risk. The user need
behind all five issues has never been addressed — only the specific mechanism was
rejected.