ask-any-follow-up-questions

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.