asking-user-questions

name	asking-user-questions
description	Use when composing an ask_user_question round inside a workflow, or when a workflow skill names it at a question step. Shared norms for the tool — not a workflow, nothing to execute.

Asking User Questions

The workflow family's shared norms for ask_user_question: how to compose rounds, shape options, and degrade when answers don't come. Process skills name this concept at the steps that ask; when to ask — and where the answers get recorded — stays with the referencing skill.

Rounds, not chat turns

• One call = one round: up to 4 questions, 2–4 options each. Group everything the current step needs into a single round — never chain a second call straight after for a trivial follow-up.
• The call ends your turn. The questionnaire is shown and your run stops; the answers arrive as the next user message (a structured "User has answered your questions:" message). Don't keep working on the blocked step after calling, and don't assume an answer until it arrives — whether that is seconds later or days later.
• If the user replies with a free-form message instead of answering the card, that reply supersedes the round — treat it as their answer, and re-ask only what is still genuinely undecided.
• Resolve the round, act on what you learned, and open a new round only when the answers raised a genuinely new question.

Options

• Recommended option first, label suffixed "(Recommended)", plus a one-line recommendedReason saying why you recommend it over the alternatives (shown inline under the option as a Why: line).
• Every option: a concise label (1–5 words, ≤ 60 chars) + a description carrying the trade-off or consequence of choosing it. Tailor options to the work at hand — never generic placeholders.
• Options must be decidable by the asked user: frame them as observable behavior or outcomes ("collapsing a project stays collapsed after a rename"), never as implementation mechanics ("semantic guard", "activation ref"). If candidate options differ only internally — identical observable behavior — don't ask: decide yourself and record the reasoning in the workflow's artifact.