| name | ask-any-follow-up-questions |
| description | Ask follow-up questions to clarify requirements, constraints, and success criteria. Do not use automatically, only when invoked explicitly. |
Ask Any Follow-Up Questions
Goal
Ask follow-up questions (must-have first, then nice-to-have) to avoid wrong work and reduce rework. Do not implement until must-have questions are answered, or the user explicitly approves proceeding with stated assumptions.
When to use
Use this skill only when explicitly invoked. Once invoked:
- You may ask clarifying questions even if the request seems mostly specified.
- Still optimize for speed: ask the smallest set that meaningfully reduces ambiguity.
Workflow
1) Identify what’s unclear or risky
After a quick mental check of how you would do the work, consider gaps in:
- Objective (what should change vs stay the same)
- Definition of done (acceptance criteria, examples, edge cases)
- Scope (files/components/users in/out)
- Constraints (compatibility, performance, style, dependencies, time)
- Environment (language/runtime versions, OS, build/test runner)
- Safety/reversibility (migrations, rollout/rollback, risk level)
If multiple plausible interpretations exist, treat as underspecified.
2) Ask must-have questions first (keep it small)
Ask 1–5 must-have questions first. Prefer questions that eliminate whole branches of work.
Make questions easy to answer:
- Numbered questions; short; scannable
- Multiple-choice options when possible
- Include recommended defaults (clearly marked)
- Include a fast-path response (e.g., reply
defaults)
- Include “Not sure — use default” when helpful
- Provide a compact reply format (e.g.,
1b 2a 3c)
3) Ask nice-to-have questions (only if useful)
After must-haves are answered (or defaults accepted), optionally ask up to 1–3 nice-to-have questions that:
- Improve UX/maintainability/perf
- Reduce future rework
- Clarify preferences (naming, style, logging, docs)
If user wants speed, skip nice-to-haves.
4) Pause before acting
Until must-have answers arrive:
- Do not run commands, edit files, or produce a plan that depends on unknowns.
- Allowed: low-risk discovery only (read docs/configs, inspect repo structure) if it doesn’t commit to a direction.
If user asks you to proceed without answers:
- State assumptions as a short numbered list
- Ask for confirmation
- Proceed only after they confirm or correct assumptions
5) Confirm interpretation, then proceed
Once answers are received:
- Restate requirements in 1–3 sentences (objective + scope + constraints + done)
- Then implement
Question templates
- “Before I start, I need: (1) … (2) … (3) …. If you don’t care about (2), I’ll assume ….”
- “Which should it be? A) … B) … C) … (pick one)”
- “What does ‘done’ look like? Example: …”
- “Any constraints (versions, perf, style, deps)? If none, I’ll target existing project defaults.”
Reply format example
1) Scope?
a) Minimal change (recommended/default)
b) Refactor while touching the area
c) Not sure — use default
2) Compatibility target?
a) Current project defaults (recommended/default)
b) Also support older versions: <specify>
c) Not sure — use default
3) Verification?
a) Existing tests only (recommended/default)
b) Add/adjust tests for new behavior
c) Not sure — use default
Reply with: defaults (or 1a 2a 3b)
Anti-patterns
- Don’t ask questions you can answer with quick, low-risk discovery reads (configs, existing patterns, docs).
- Don’t ask open-ended questions when tight options would eliminate ambiguity faster.
- Don’t “question-spam”: if answers won’t change implementation, skip.
