| name | ask-questions-if-underspecified |
| description | Ask minimal clarifying questions only when ambiguity materially changes implementation. Use for routine underspecification; do not use for user-requested light or full grilling, plan stress-testing, or broad design interviews. |
| license | CC-BY-SA-4.0 |
Ask Questions If Underspecified
Use this skill when a request has multiple plausible implementations and picking the wrong one would cause rework, risk, or incorrect outcomes. This skill is intentionally narrow: it should unblock work with the fewest questions possible.
When to Use
- Key details are unclear: objective, done criteria, scope, constraints, environment, or safety
- Multiple reasonable interpretations would lead to materially different work
- You cannot resolve ambiguity with quick, read-only discovery
When NOT to Use
- The request is clear enough to proceed safely
- A quick repo read (files/config/docs) can answer the unknowns
- Repo conventions provide a safe default and ambiguity is low impact
- The user wants light or full grilling or plan stress-testing; use
grilling or /grill instead
Rules
- Ask the minimum needed to unblock work (prefer one targeted question).
- Use the client's structured question capability when available; otherwise ask one concise question in chat.
- Put recommended/default choices first and tag them with
(Recommended).
- Do all non-blocked, low-risk discovery first.
- Until must-have answers arrive, do not edit files or run state-changing commands.
- If the user asks to proceed without answers, state assumptions briefly and continue with safest defaults.
- Never turn this into a multi-round design interview unless the user explicitly invokes
/grill or asks to be grilled.
Workflow
- Run quick discovery (read-only) to remove guesswork.
- Identify only must-have unknowns that change implementation direction.
- Ask 1-3 concise questions max in the first pass.
- Prefer multiple-choice options over open-ended prompts.
- Include a low-friction fallback, e.g.
Use recommended defaults.
- After answers, restate requirements in 1-3 sentences and proceed.
Must-Have Clarification Areas
- Objective: what should change and what should stay the same
- Definition of done: acceptance criteria, examples, edge cases
- Scope: what is in/out
- Constraints: compatibility, performance, style, dependency limits
- Environment: runtime/tooling versions when relevant
- Safety: migration, rollback, irreversible actions
Anti-Patterns
- Asking questions answerable via quick discovery
- Asking broad/open questions when options would be clearer
- Running a light or full grilling session under this skill instead of
/grill
- Asking permission for routine safe steps
- Blocking on nice-to-know details that can use project defaults
- Asking users to reply with numbered text when the client can capture structured choices
