Ask Clarifying Questions Before Starting Underspecified Work

This skill clarifies underspecified requirements before implementation starts. It treats a request as underspecified if, after exploring how to do the work, the objective, "done" criteria, scope, constraints, environment, or safety and reversibility are still unclear, or if multiple plausible interpretations exist. It asks the minimum set of must-have questions needed to avoid wrong work, in a first pass of 1-5 questions that eliminate whole branches of work, and does not start implementing until those are answered or the user explicitly approves proceeding on stated assumptions.

Use it when a request has multiple plausible interpretations or key details, such as objective, scope, constraints, environment, or safety, are unclear. Do not use it when the request is already clear, or when a quick, low-risk discovery read, such as checking configs, existing patterns, or docs, can answer the missing details without asking.

Questions are optimized for scannability: short, numbered, offering multiple-choice options, marking a recommended default clearly (bolded, or called out just above a code block), including a fast-path reply like defaults to accept every recommended choice, a low-friction "not sure - use default" option, and a compact reply format such as 1a 2a. Until must-have answers arrive, the skill does not run commands, edit files, or produce a plan that depends on the unknowns - it may only perform a clearly labeled, low-risk discovery step that commits to nothing. If the user explicitly asks to proceed without answering, the skill states its assumptions as a short numbered list and asks for confirmation before continuing. Once answers arrive, it restates the requirements in 1-3 sentences, including key constraints and what success looks like, before starting work. It ships question templates and a worked example format:

1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default

Reply with: defaults (or 1a 2a)

Not tied to any specific tool or language - it is a general-purpose clarification protocol applicable to any implementation task where ambiguity would otherwise lead to wrong work.

AI coding agents and their operators who want ambiguous requests clarified with a small, scannable set of multiple-choice questions before any code is written, rather than either guessing silently or interrogating the user with open-ended paragraphs. Two explicit anti-patterns to avoid: asking a question that a quick, low-risk discovery read could already answer, and asking an open-ended question when a tight multiple-choice or yes/no one would eliminate the ambiguity faster.