Feature: Native plugin UI dialogs (like /mcp) for third-party plugins

Summary

Claude Code has a polished native UI dialog for /mcp — users can browse, select, and interact with MCP servers without any AI response. Third-party plugins have no equivalent. They are limited to systemMessage injection and Claude chat responses, which forces every plugin interaction through the AI layer even when it's unnecessary.

Problem

Today, plugins can only interact with users via:

• systemMessage — silent context injection (user sees nothing directly)
• Skill + Claude response — AI processes and responds (slow, wastes tokens, feels wrong for pure UI tasks)

This makes it impossible to build plugins with clean, immediate UI like:

• Documentation browsers (/docs → pick service → pick topic → docs injected)
• Service pickers, config wizards, command palettes
• Anything that should be instant and deterministic, not AI-generated

Real example: I built quickdocs — a documentation fetcher that injects official docs into Claude context. The CLI has a great arrow-key interactive picker. Inside Claude Code, the best I can do is a skill that asks Claude to show a numbered list and wait — which still goes through the AI, wastes tokens, and feels sluggish compared to /mcp.

Proposed Solution

Expose a plugin UI primitive — a simple dialog/picker that plugins can trigger natively, similar to how /mcp works internally.

Option A: dialog hook output type

Allow hooks to return a dialog response that Claude Code renders natively:

{
  "dialog": {
    "type": "list",
    "title": "Select a service",
    "items": [
      { "label": "Stripe — Payment APIs", "value": "stripe" },
      { "label": "Vercel — Frontend cloud", "value": "vercel" }
    ],
    "onSelect": "bash /path/to/plugin/hooks/on-select.sh"
  }
}

Option B: Plugin-registered slash commands with native rendering

Allow plugins to register slash commands that render a native UI step before passing to Claude:

{
  "commands": {
    "/docs": {
      "steps": [
        { "type": "list", "source": "bash plugin/hooks/list-services.sh" },
        { "type": "list", "source": "bash plugin/hooks/list-topics.sh --service=$SELECTION" }
      ],
      "onComplete": "inject-context"
    }
  }
}

Option C: Minimal — just expose a userVisible output from hooks

Hooks currently inject systemMessage (silent). Add a userMessage field that renders directly in the chat UI without requiring a Claude response:

{
  "userMessage": "Here are your docs:\n\n...",
  "suppressAiResponse": true
}

Why This Matters

• Token efficiency — UI tasks (pick a service, browse topics) don't need AI. Routing them through Claude wastes context and adds latency.
• Plugin quality ceiling — right now all plugins feel like "AI wrappers". Native UI primitives would enable plugins that feel like real tools.
• Consistency — /mcp, /help, /config all have native UI. Third-party plugins should have the same capability.
• Ecosystem growth — developer tools (doc browsers, API explorers, schema viewers) are natural Claude Code plugins but can't be built well today.

References

• quickdocs — example plugin blocked by this limitation
• Current workaround: hook + skill + Claude response (3-layer hack for what should be 1 native call)