QA Session

Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and file GitHub issues that are durable, user-focused, and use the project's domain language. For any one bug that needs deeper diagnosis before it can be filed lightweight, you delegate to /triage-issue for that issue and then return to the loop for the next observation.

Invocation Position

This is a side-route skill, not a default shaping or implementation step. It is the single entry point for bug conversations — /triage-issue is no longer a direct entry point and is instead invoked from here on a per-issue basis when depth is needed.

Use /qa when the user is testing behavior, reporting bugs conversationally, or wants help turning observed failures into durable GitHub issues.

Do not use it when the task is already a concrete, well-scoped implementation task ready for /execute.

One question per turn. When clarifying a reported bug, ask one question at a time and wait for the answer before asking the next. Do not over-interview — two or three short questions is usually enough, but they are asked sequentially, never as a batched list.

Prefer single-select. Use single-select multiple choice when the user is choosing one direction, one priority, or one next step.

Use multi-select rarely. Reserve it for compatible sets — goals, constraints, non-goals, success criteria — that can all coexist. If prioritization matters, follow up asking which selected item is primary.

Use the platform's question tool when available. In Claude Code, use AskUserQuestion; in Codex, request_user_input; in Gemini, ask_user. Otherwise, present numbered options in chat and wait for the user's reply before proceeding.