Summary
Please add visible/discoverable VS Code UX for common Hermes chat/session slash commands, similar to the WebUI request in nesquena/hermes-webui#1804.
The goal is that users should not need to memorize /new, /clear, /steer, /interrupt, /queue, /stop, etc. to control a Hermes ACP session from the VS Code extension.
User workflow
In WebUI I ran into the question:
How do I start a fresh /new session inside a chat?
The answer was “type /new”, but that made it clear these commands should be discoverable as UI actions. The same applies in VS Code: during coding work, users are already scanning the chat header/composer/status bar/Command Palette, not necessarily remembering text commands.
Requested VS Code UX
Expose common Hermes commands through VS Code-native surfaces, ideally backed by the same underlying command/session paths as slash commands so behavior does not drift.
Suggested surfaces:
- Chat/webview toolbar or kebab menu
- Composer action menu
- VS Code Command Palette entries (
Hermes: ...)
- Optional keybindings for high-frequency actions
- Status bar / running-session affordance while a task is active
Commands/actions to expose
Session/view controls
- New Hermes chat/session — equivalent to
/new or CLI /reset semantics where appropriate.
- Clear current conversation/view — equivalent to
/clear.
- Retry last prompt — equivalent to
/retry.
- Undo last exchange — equivalent to
/undo.
- Set/rename title — equivalent to
/title.
Active-run / busy-state controls
- Stop/Cancel current run — equivalent to
/stop / hard cancel.
- Queue next message — equivalent to
/queue <message>.
- Interrupt and replace instruction — equivalent to
/interrupt <message>.
- Steer current run — equivalent to
/steer <message>.
The active-run controls should explain the difference clearly:
- Queue = run this after the current response finishes.
- Interrupt = stop the current response and send this new instruction instead.
- Steer = nudge the current run without stopping it, preserving workflow context where supported.
- Stop = cancel the current run.
Other useful candidates
/compress / /compact/background/btw/status/usage/model/reasoning/yolo
Not every item needs a large permanent button. A command palette / composer action menu with good grouping would be enough for many of these.
Busy-state behavior
When an ACP/Hermes session is running, the extension should make the safe available choices obvious:
- show quick actions for Stop, Steer, Interrupt, and Queue;
- disable or explain actions that are invalid in the current state;
- avoid silently treating session-control commands as normal text when the user intended a control action;
- preserve context after steer/interrupt where Hermes supports it.
Why this matters
This would make the VS Code extension feel more like a first-class Hermes UI rather than a generic chat box that requires hidden command knowledge.
It is especially useful for:
- long coding tasks where the user sees the agent going in the wrong direction and wants to steer quickly;
- multi-step agent workflows where queue/interrupt/stop decisions save time and tokens;
- users switching between Hermes CLI, WebUI, and VS Code;
- discoverability for new users who expect VS Code actions and Command Palette entries.
Related issues
This issue is broader than #13: #13 focuses on steering/interrupting active work, while this request asks for a coherent discoverability/action-surface design for both session controls and active-run controls.
Acceptance criteria
- A user can start a new Hermes chat/session in VS Code without knowing
/new.
- A user can clear the current conversation/view without knowing
/clear.
- A user can discover and invoke Stop, Queue, Interrupt, and Steer controls while a run is active.
- Tooltips/descriptions expose the slash equivalents where relevant.
- VS Code Command Palette includes sensible
Hermes: ... entries for core actions.
- UI actions and slash commands share underlying behavior where practical.
- Invalid/busy/idle states are handled intentionally with clear disabled states or explanations.
Summary
Please add visible/discoverable VS Code UX for common Hermes chat/session slash commands, similar to the WebUI request in nesquena/hermes-webui#1804.
The goal is that users should not need to memorize
/new,/clear,/steer,/interrupt,/queue,/stop, etc. to control a Hermes ACP session from the VS Code extension.User workflow
In WebUI I ran into the question:
The answer was “type
/new”, but that made it clear these commands should be discoverable as UI actions. The same applies in VS Code: during coding work, users are already scanning the chat header/composer/status bar/Command Palette, not necessarily remembering text commands.Requested VS Code UX
Expose common Hermes commands through VS Code-native surfaces, ideally backed by the same underlying command/session paths as slash commands so behavior does not drift.
Suggested surfaces:
Hermes: ...)Commands/actions to expose
Session/view controls
/newor CLI/resetsemantics where appropriate./clear./retry./undo./title.Active-run / busy-state controls
/stop/ hard cancel./queue <message>./interrupt <message>./steer <message>.The active-run controls should explain the difference clearly:
Other useful candidates
/compress//compact/background/btw/status/usage/model/reasoning/yoloNot every item needs a large permanent button. A command palette / composer action menu with good grouping would be enough for many of these.
Busy-state behavior
When an ACP/Hermes session is running, the extension should make the safe available choices obvious:
Why this matters
This would make the VS Code extension feel more like a first-class Hermes UI rather than a generic chat box that requires hidden command knowledge.
It is especially useful for:
Related issues
This issue is broader than #13: #13 focuses on steering/interrupting active work, while this request asks for a coherent discoverability/action-surface design for both session controls and active-run controls.
Acceptance criteria
/new./clear.Hermes: ...entries for core actions.