q-interactive

What this skill does

# Q-Interactive — Structured Question Mode

Instead of asking questions inline as text, collect every open question or decision point about the current task and present them **one at a time** using the `AskUserQuestion` tool.

This matters because inline questions are easy to miss, hard to answer precisely, and often bury important trade-offs in paragraphs of text. Structured questions with concrete options let the user make fast, informed decisions without having to parse your reasoning first.

## Most Common Trigger: Retroactive Restructuring

The typical flow is: you already responded with a wall of questions or options, and the user replies with "use q-interactive" or just "q-interactive." This means: go back to what you just said, extract the questions/decisions from your previous response, and re-present them using the structured format below — one at a time via `AskUserQuestion`. Don't start from scratch or re-analyze the task; restructure what you already asked.

## Workflow

### Step 1 — Collect

Identify ALL pending questions and decisions. If this is a **retroactive trigger** (user said "q-interactive" after your previous response), extract the questions from your last message. If this is a **proactive trigger** (user asks you to help decide something), think through the task end-to-end and inventory every point where you need input. Group related questions and present them in logical order.

### Step 2 — Present One at a Time

Present each question as a separate `AskUserQuestion` call. Each question should have:

- **header** — A short category tag (max 12 characters). Examples: "Approach", "Library", "Scope", "Target", "Style", "Testing", "Deploy"
- **question** — A complete, specific question ending with `?`
- **2-4 options** — Concrete, actionable choices (not vague). Each option needs:
  - **label** — Short name for the choice. If you have a recommendation, put it first and append `(Recommended)` to its label
  - **description** — Explain WHY you'd choose this option — trade-offs, consequences, or justification. For the recommended option, explain why it's the best default. The description is where the real value is — it gives the user the rationale they need to decide confidently

### Step 3 — Summarize and Proceed

Once all questions are answered, briefly summarize the decisions made, then proceed with the task using those answers. No need to re-ask or second-guess — the user made their choices.

## Example

For a question about testing approach:

- **header:** "Testing"
- **question:** "Which testing strategy should we use for the new API endpoints?"
- **options:**
  1. **label:** "Integration tests (Recommended)", **description:** "Tests against a real database — catches schema mismatches and query bugs that unit tests miss. Slower but higher confidence."
  2. **label:** "Unit tests with mocks", **description:** "Faster to run and write, but won't catch issues at the boundary between code and database."
  3. **label:** "Both", **description:** "Maximum coverage but doubles the testing surface to maintain. Best for critical paths."

## When NOT to Use

- If there's only one question — just ask it inline, no need for the ceremony
- If the decision is trivial or has an obvious answer — just proceed and mention what you chose
- If the user is in a rush and said something like "just do it" — respect that, make reasonable defaults