[Feature Request] Tab autocomplete should complete to longest common prefix, not full-accept first match

Bug Description

# Claude Code feedback Title: Tab in slash-command autocomplete should complete to longest common prefix (readline-style), not full-accept the highlighted entry ## Problem In the slash-command/skill autocomplete menu, Tab (autocomplete:accept) immediately inserts and accepts the _highlighted_ entry. When the typed prefix is ambiguous, this jumps to whatever's highlighted first — often not what I want. Example: I have the claude-reflect plugin (commands reflect, reflect-skills, view-queue, skip-reflect). Typing /claude-ref + Tab completes all the way to /claude-reflect:view-queue — a command I almost never run — instead of stopping at the shared prefix. ## Requested behavior Make Tab complete to the _longest common prefix_ of the remaining candidates and keep the dropdown open, like readline/shell tab-completion: - /claude-ref + Tab → /claude-reflect: (common prefix of all matches), menu stays open. - Next Tab (or more typed chars) narrows further; Tab only full-accepts once a single candidate remains. This is especially valuable for namespaced plugin commands (plugin:command), where the namespace is the natural common-prefix stopping point. ## Possible implementation - Add a distinct action (e.g. autocomplete:completePrefix) bindable in the Autocomplete context, OR - Change autocomplete:accept to do prefix-completion when multiple candidates match and full-accept only when one remains. - Add an option to configure stop separators (e.g. [':', '-']) so that Tab stops at the separator boundary. ## Workaround today None exact — currently must type past the ambiguity or arrow-key to the target before Tab. The keybinding action set only exposes full-accept.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.165
• Feedback ID: cbedafd8-d056-44a7-9d3a-3ec600dfac58

Errors

[]