Slash commands: structured prompts for user input (choice, text, confirm)

Preflight Checklist

• [x] I have searched existing issues to ensure this feature hasn't been requested
• [x] I have verified this feature doesn't exist in the current version

Problem Statement

Slash commands (.claude/commands/*.md) are powerful for encoding team workflows, but they have no way to collect structured input from the user during execution. When a command needs the user to make a choice (e.g., pick from a list), confirm an action, or provide freeform text, the only option is to emit a text prompt and hope the user replies in a parseable way.

This limitation surfaced while building a team-wide shared slash commands improvement and feedback iteration tool — commands needed to present vote options (thumbs up / thumbs down / suggest improvement) and collect optional comments, but there's no mechanism to do this reliably. The Bash tool doesn't support interactive stdin, so tools like gum, select, or read aren't viable either.

Proposed Solution

Add optional frontmatter to slash command .md files that declares structured prompts. Claude Code would render these as native TUI elements (selection lists, text inputs, confirmation dialogs) before executing the command body, and inject the responses as variables.

Example frontmatter:

---
prompts:
  - name: vote
    type: choice
    message: "How was this beta command?"
    options:
      - label: "👍 This is an improvement"
        value: "up"
      - label: "👎 I prefer the original"
        value: "down"
      - label: "🔧 Suggest a tweak"
        value: "tweak"
  - name: feedback
    type: text
    message: "Any feedback? (optional)"
    required: false
  - name: confirm_submit
    type: confirm
    message: "Submit your vote?"
---

The command body would then reference $PROMPT_VOTE, $PROMPT_FEEDBACK, $PROMPT_CONFIRM_SUBMIT (or similar variable naming).

Alternative Solutions

1. AskUserQuestion tool from within commands — slash commands could invoke AskUserQuestion, but this requires the AI to generate the prompt each time rather than declaring it statically, and the presentation isn't consistent.
2. External TUI tools (gum, fzf) — these require users to install additional dependencies, creating adoption friction for team-wide commands.
3. MCP server with prompt capabilities — an MCP server could expose structured prompt tools, but this is heavyweight for what should be a simple declarative feature built into the command format. Teams would need to deploy and configure an MCP server just to get basic input collection, adding significant operational overhead.
4. Convention-based text prompts — emit numbered options as text and parse the user's reply. This works but is fragile and doesn't provide a native UI experience.

Priority

Medium — this would significantly improve the slash command ecosystem for teams building shared workflows, but text-based prompting works as a fallback.

Category

Interactive mode (TUI)

Use Case Example

A team maintains shared slash commands for code review, commit workflows, and feedback collection. Several commands need to:

• Present a list of options (e.g., commit type, review verdict, vote direction)
• Collect optional freeform text (e.g., review comments, vote feedback)
• Confirm destructive actions (e.g., force-push, publish)

Currently each command reimplements this as unstructured text, leading to inconsistent UX and fragile parsing. Declared prompts would make these interactions reliable and visually consistent.

Additional Context

This would complement the existing $ARGUMENTS mechanism — arguments are for inline invocation (/command arg1 arg2), while prompts would be for interactive multi-step input that benefits from a richer UI.