Favorites bar for custom slash commands, pinned above the chat input

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

Projects with several custom slash commands currently have no fast, reliable way to access them. The only options are: (1) memorize exact command names and type them from scratch, or (2) type / and scan a long list that also includes every built-in command and skill — not just the ones relevant to this project. This gets worse as a project accumulates more custom commands (mine has six, covering session start, drift-checking, deploy fixes, migrations, and recovery). It's also compounded by reliability issues reported with the / autocomplete picker sometimes not surfacing custom commands from .claude/commands/ at all.
The real cost shows up with commands meant to enforce guardrails at specific moments — a session-start check, a mid-session drift check before continuing risky work. If these aren't visible or top-of-mind, it's easy to simply forget to run them, and work then proceeds without the intended check ever happening — not because the guardrail failed, but because it was silently skipped. That's a worse failure mode than a missed shortcut: it's a safety step quietly not applied, with no indication anything was skipped at all.

Proposed Solution

Let users mark up to 5 slash commands (built-in, custom, or skills) as favorites. Display them as one-click buttons in a row directly above the message input in the Desktop app. Clicking a favorite fills the input with that command and submits immediately — no typing, no navigating the full picker. Being persistently visible also makes them a passive reminder for guardrail/habitual commands specifically, reducing the risk of a check being skipped simply because it wasn't remembered.

Alternative Solutions

Custom keybindings (/keybindings, already available) — lets you bind a key to a specific command, but it's not self-documenting: you have to remember which key maps to which command, which doesn't scale past a couple of bindings and isn't visible to anyone returning to the project later — so it doesn't solve the "forgot the guardrail even exists right now" problem.
Fixing the autocomplete picker's reliability directly — would solve the "custom commands sometimes don't appear" bug, but wouldn't reduce the underlying friction of typing and remembering exact names for commands used constantly.
Pre-filled draft text in the input box — would let a command sit ready to send by default, but requires manually deleting it when not needed, rather than simply not clicking a button. Also not currently a supported feature.
Hooks that auto-run guardrail logic without user action (e.g., a PreToolUse hook before risky actions) — genuinely solves the "forgetting" problem for a specific trigger, but is a silent background check rather than an active, visible one the user consciously engages with. A favorites bar keeps the human in the loop deliberately, rather than delegating the check to an automated hook the user might not think to review.

A visible favorites bar addresses both the convenience friction and the guardrail-skipping risk more directly than any of these alone, and is complementary to hooks and keybindings rather than a replacement for either.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. I'm working on a real codebase with six custom slash commands set up in .claude/commands/ — session start, mid-session drift check, deploy-error protocol, database migration, break-glass recovery, and commit/push.
2. I need to run these at specific moments during a session — session start, before a risky change, before touching a migration — but currently have to either remember the exact command name and type it, or type / and scroll past every built-in command and skill to find mine.
3. With this feature, I could pin my 6 most important commands as one-click favorites above the input, so they're always visible and a single click away — no memorizing names, no scrolling through the full picker.
4. This would save me time because I wouldn't have to stop and recall or search for a command name mid-task — and more importantly, it would reduce the risk of simply forgetting to run a guardrail command (like a pre-deploy or drift check) because it wasn't visible or top-of-mind at the moment it mattered.

Additional Context

_No response_