feat: migrate CLI-only skills/commands (e.g. /handoff) to run in WebUI instead of surfacing-then-refusing

[nesquena-hermes]

Summary

CLI-only commands/skills (e.g. /handoff) are surfaced in the WebUI slash-command autocomplete dropdown but refuse to execute, returning "/<name> is a Hermes CLI-only command and cannot run inside the WebUI." This is confusing: the command appears selectable, the user picks it, and then it dead-ends. Several CLI-only skills/commands have not yet been migrated to run in the WebUI.

Steps to reproduce

1. Open WebUI chat
2. Type / and select (or type) a CLI-only command/skill, e.g. /handoff
3. Send
4. Observed: assistant returns "/handoff is a Hermes CLI-only command and cannot run inside the WebUI."
5. Expected (longer-term): the command runs in the WebUI like it does in hermes chat / Discord

Current behavior / mechanism

• Skills with slash triggers surface in the dropdown (shipped in feat: surface skill slash commands in Web UI autocomplete dropdown #460), and CLI-only commands are gated at execution time.
• static/commands.js:237 — cliOnlyCommandResponse() produces the refusal string.
• api/commands.py:87 — commands carry a cli_only flag from the agent's command metadata; static/commands.js:87 filters cli_only commands out of the command list, but skill-sourced entries (like /handoff) still surface and then hit the CLI-only refusal on execution.

Desired behavior

Migrate CLI-only skills/commands so they can run inside the WebUI (the long-term direction confirmed by @AvidFuturist: "Handoff is a special CLI only skill we haven't migrated to WebUI yet, but we will in the future"). For ones that genuinely cannot be migrated, consider hiding them from autocomplete (or visually marking them as CLI-only) so users aren't offered a command that can't run.

/handoff is the concrete example raised, but this is a tracking issue for the broader set of CLI-only commands/skills surfaced in the WebUI.

Scope

Cross-layer (WebUI + bundled agent), per-command. Larger than a one-file fix — each CLI-only command needs either a WebUI execution path or an explicit "cannot migrate → hide/mark" decision. Suggest enumerating the current cli_only set first.

Reported by

@Latipun in Discord #webui (2026-06-11): asked why /handoff shows the CLI-only message. Confirmed by @AvidFuturist, who committed to migrating these in the future and asked to capture the request.

[nesquena-hermes]

Reporter screenshot (via @AvidFuturist, Discord #webui):

Confirms the surface-then-refuse behavior, and surfaces an additional wrinkle worth noting: there appear to be two different /handoff concepts colliding in the UI.

• The refusal message describes the CLI command meaning: "/handoff is a Hermes CLI-only command and cannot run inside the WebUI. Hand off this session to a messaging platform (Telegram, Discord, etc.)."
• The autocomplete dropdown entry is badged SKILL with a different description: "Compact the current conversation into a handoff document for another agent to pick up."

So the dropdown is advertising the skill meaning while execution dead-ends on the CLI-command refusal. Whatever the migration/hide decision is, the name collision between the CLI /handoff command and the handoff skill should be resolved too (one of them likely needs to be disambiguated or the skill should be the one that runs).