From amplify
Pauses to ask 1-5 focused clarifying questions when tasks are underspecified by objective, scope, constraints, or acceptance criteria, avoiding wasted work on vague requests.
npx claudepluginhub wunki/amplify --plugin ask-questions-if-underspecifiedThis skill uses the workspace's default tool permissions.
Ask the minimum set of clarifying questions needed to avoid wrong work. Never start
Asks minimal clarifying questions to resolve underspecified requirements like objectives, scope, constraints, and acceptance criteria before implementing. Invoke explicitly via /ask-questions-if-underspecified.
Asks targeted clarifying questions when requests lack clear objectives, scope, constraints, environment, or acceptance criteria before implementing.
Asks 1-5 targeted questions to clarify objectives, scope, constraints, acceptance criteria on underspecified tasks before implementing. Explicit invocation only.
Share bugs, ideas, or general feedback.
Ask the minimum set of clarifying questions needed to avoid wrong work. Never start implementing until must-have questions are answered — or the user explicitly approves proceeding with stated assumptions.
Before asking anything, scan earlier messages in the current thread. Requirements already discussed are not underspecified. If prior messages resolve the ambiguity, proceed directly to Step 4.
After inspecting the codebase or task context as needed, treat a request as underspecified if two or more of the following are unclear:
If only one criterion is unclear and a low-risk discovery read can resolve it (e.g., checking a config file), do that read and proceed. Do not ask the user for something that can be looked up.
If multiple plausible interpretations exist that would lead to meaningfully different implementations, treat it as underspecified regardless of criterion count.
Ask 1–5 questions in a single pass. Prefer questions that eliminate entire branches of work. Cap at one clarification round — if further ambiguity surfaces after answers arrive, use judgment to pick the most reasonable interpretation rather than asking again.
Make questions easy to answer:
defaults accepts all recommendations1b 2a 3c; restate the chosen options in plain
language to confirm before proceedingUntil must-have answers arrive:
If the user explicitly says to proceed without answers (e.g., "just do it", "make reasonable assumptions"):
Once answers are in, restate requirements in 1–3 sentences — including key constraints and what success looks like — then start work.
Before I start, I need: (1) ..., (2) ..., (3) ....
If you don't care about (2), I will assume ....
Which of these should it be?
A) ... (default)
B) ...
C) Not sure — use default
What counts as "done"? For example: ...
Any constraints to follow (versions, performance, style, deps)?
If none, I will target the existing project defaults.
Compact multi-question format:
1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure — use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure — use default
Reply: defaults | 1a 2b | correct any option