Agent skill

ask-questions-if-underspecified

Clarify requirements before implementing. Do not use automatically, only when invoked explicitly.

Stars 12
Forks 2

Install this agent skill to your Project

npx add-skill https://github.com/enitrat/skill-issue/tree/main/plugins/base-config/skills/ask-questions-if-underspecified

SKILL.md

Ask Questions If Underspecified

Goal

Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).

Workflow

1) Decide whether the request is underspecified

Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:

  • Define the objective (what should change vs stay the same)
  • Define "done" (acceptance criteria, examples, edge cases)
  • Define scope (which files/components/users are in/out)
  • Define constraints (compatibility, performance, style, deps, time)
  • Identify environment (language/runtime versions, OS, build/test runner)
  • Clarify safety/reversibility (data migration, rollout/rollback, risk)

If multiple plausible interpretations exist, assume it is underspecified.

2) Ask must-have questions first (keep it small)

Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.

Make questions easy to answer:

  • Optimize for scannability (short, numbered questions; avoid paragraphs)
  • Offer multiple-choice options when possible
  • Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice; bold the recommended choice in the list, or if you present options in a code block, put a bold "Recommended" line immediately above the block and also tag defaults inside the block)
  • Include a fast-path response (e.g., reply defaults to accept all recommended/default choices)
  • Include a low-friction "not sure" option when helpful (e.g., "Not sure - use default")
  • Separate "Need to know" from "Nice to know" if that reduces friction
  • Structure options so the user can respond with compact decisions (e.g., 1b 2a 3c); restate the chosen options in plain language to confirm

3) Pause before acting

Until must-have answers arrive:

  • Do not run commands, edit files, or produce a detailed plan that depends on unknowns
  • Do perform a clearly labeled, low-risk discovery step only if it does not commit you to a direction (e.g., inspect repo structure, read relevant config files)

If the user explicitly asks you to proceed without answers:

  • State your assumptions as a short numbered list
  • Ask for confirmation; proceed only after they confirm or correct them

4) Confirm interpretation, then proceed

Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.

Question templates

  • "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) ... B) ... C) ... (pick one)"
  • "What would you consider 'done'? For example: ..."
  • "Any constraints I must follow (versions, performance, style, deps)? If none, I will target the existing project defaults."
  • Use numbered questions with lettered options and a clear reply format
text
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 with: defaults (or 1a 2a)

Anti-patterns

  • Don't ask questions you can answer with a quick, low-risk discovery read (e.g., configs, existing patterns, docs).
  • Don't ask open-ended questions if a tight multiple-choice or yes/no would eliminate ambiguity faster.

Expand your agent's capabilities with these related and highly-rated skills.

enitrat/skill-issue

tdd

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

12 2
Explore
enitrat/skill-issue

sdk-documentation

Rules and patterns for writing comprehensive, high-quality SDK documentation for public libraries. Covers documentation architecture, narrative tone, user guides, and API references. Use when: (1) Writing or reviewing documentation for a public SDK/library, (2) Creating API reference pages for hooks/functions/classes, (3) Writing getting-started guides or tutorials, (4) Structuring a documentation site from scratch, (5) Reviewing documentation quality and consistency, (6) Setting up a VitePress or GitBook documentation site for an SDK.

12 2
Explore
enitrat/skill-issue

super-ralph

Build multi-phase AI development pipelines with the Smithers workflow engine (v0.8.2). Use when: (1) Setting up a SuperRalph workflow for a repo (focuses, focusDirs, focusTestSuites, agents) (2) Debugging a run (ticket explosion, duplicate tickets, stalled nodes) (3) Understanding the pipeline phases and what generates tickets (4) Avoiding common configuration mistakes that cause runaway ticket counts

12 2
Explore
enitrat/skill-issue

prd-authoring

12 2
Explore
enitrat/skill-issue

tanstack-best-practices

Best practices for building hook libraries with TanStack Query. Use when: (1) Writing useQuery/useMutation hooks that wrap async data-fetching functions, (2) Designing query key schemas and cache identity systems, (3) Building framework-agnostic query options factories, (4) Implementing cache invalidation patterns (invalidate vs remove vs setQueryData), (5) Wrapping TanStack Query in a multi-layered library (core actions to query options to framework hooks), (6) Handling non-serializable values (bigint, class instances) in query keys, (7) Bridging external stores (zustand, signals) with TanStack Query reactivity. Derived from wagmi's production architecture (React/Vue/Solid Ethereum hooks).

12 2
Explore
enitrat/skill-issue

smithers

Build multi-phase AI development pipelines with the Smithers workflow engine (v0.8.2). Use when: (1) Initializing a new Smithers project in a target directory (use the init CLI) (2) Adding phases or steps to existing workflows (3) Implementing review loops, pass tracking, or phase gating (4) Debugging workflow orchestration issues (Ralph loops, ctx.output, data threading) (5) Writing instruction MDX files for project configs (6) Configuring agents or per-role overrides

12 2
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results