requirements-gathering

Ask clarifying questions one topic at a time covering the real problem, target users, must-haves versus nice-to-haves, technical constraints, and delivery format. Continue until you can describe the project back to the requester and they confirm your understanding.

Ask about the pain point being solved, who will use it, must-have features, tech stack and platform constraints, delivery location, security boundaries, and approval workflow. Ask each topic sequentially rather than all at once to avoid overwhelming the requester.

Skip questions only when given a complete step-by-step specification with exact file paths, contents, and commands. In that case execute verbatim without substituting dependencies or improving the spec. For partial specs, execute the specified parts and ask only about the gaps.

A project vision document is a structured summary written after gathering all answers, covering overview, features, architecture, user interface, and delivery method. It is presented to the requester for explicit confirmation before any building begins.

Skipping requirements gathering causes rework because assumptions fill gaps in the request incorrectly. Even simple-seeming requests hide ambiguity about delivery location, audience, and constraints that only surface after the wrong thing is built.