[Question] Why do plugin skills use `/` prefix while standalone skills use `$` in web UI?

[axisrow]

Question

In native Claude Code CLI, both plugin skills and standalone skills are invoked via /skill-name. However, in the hapi web interface, there is a difference:

• Plugin skills (e.g., feature-dev:feature-dev) are accessible via / prefix in the autocomplete — they are registered as slash commands through scanPluginCommands() which scans <pluginDir>/commands/
• Standalone skills (from ~/.claude/skills/) are only accessible via $ prefix — a separate trigger character with a separate discovery mechanism (listSkills())

Context

In web/src/router.tsx (lines 276-281), the autocomplete routing splits by prefix:

if (query.startsWith('$')) {
    return await getSkillSuggestions(query)  // standalone skills
}
return await getSlashSuggestions(query)      // slash commands + plugin commands

Standalone skills are served by a separate RPC endpoint (listSkills) and use $, while plugin commands are included in the slash commands list (listSlashCommands) and use /.

Is this intentional design, or should standalone skills also be accessible via / to match native Claude Code CLI behavior? Are there specific reasons for keeping $ as a separate trigger for standalone skills?

[github-actions]

The current HAPI web implementation keeps these as two separate autocomplete systems.

What is available under / today is the slash-command path, which includes built-ins plus user/plugin/project commands. In the web route, $... is explicitly sent to useSkills(), while everything else goes to useSlashCommands() (web/src/router.tsx:276). The composer also registers / and $ as separate trigger prefixes (web/src/components/AssistantChat/HappyComposer.tsx:85).

On the backend, this split continues:

• /api/sessions/:id/slash-commands and /api/sessions/:id/skills are separate endpoints (hub/src/web/routes/sessions.ts:386, hub/src/web/routes/sessions.ts:412).
• listSlashCommands() scans command sources, including Claude plugin commands/ directories, and returns built-in/user/plugin/project commands (cli/src/modules/common/slashCommands.ts:219, cli/src/modules/common/slashCommands.ts:274).
• listSkills() separately scans skill roots such as ~/.agents/skills, ~/.claude/skills, project .agents/.claude skill dirs, and /etc/codex/skills (cli/src/modules/common/skills.ts:24, cli/src/modules/common/skills.ts:140).

So, based on the current code, standalone skills are not exposed via / in the web UI. They are only exposed through the $ skill suggestion path.

I did not find a code comment, README note, or other in-repo documentation that states the reason for this split, so I cannot verify whether it was a deliberate UX decision or just the current implementation shape.

Relevant code:

• web/src/router.tsx:276 - routes $ queries to skills; others to slash commands
• web/src/components/AssistantChat/HappyComposer.tsx:85 - composer enables separate @, /, $ prefixes
• web/src/hooks/queries/useSlashCommands.ts:89 - slash suggestions only include user / plugin / project command sources
• web/src/hooks/queries/useSkills.ts:60 - skill suggestions are built from $... queries and rendered back as $skill
• hub/src/web/routes/sessions.ts:386 - separate slash-command endpoint
• hub/src/web/routes/sessions.ts:412 - separate skills endpoint
• cli/src/modules/common/slashCommands.ts:219 - plugin commands come from plugin commands/ dirs
• cli/src/modules/common/skills.ts:140 - standalone skills are discovered by separate skill-root scanning

---

HAPI Bot