discovery-interview

Run a structured discovery interview that asks category-by-category questions about the problem, users, data, integrations, and scale. The process detects knowledge gaps, offers research on uncertain topics, and writes a complete spec only after a completeness checklist passes.

Cover problem definition, user journeys, data and state, technical constraints, scale expectations, integrations, security, and deployment. The interview requires at least 10-15 questions across these categories, with at least two per relevant category.

Yes. The interview adapts to non-technical users by using analogies, offering more research options, and avoiding overwhelming technical choices. It educates users on tradeoffs so they make informed decisions rather than uninformed guesses.

Detected conflicts, such as wanting real-time updates with cheap infrastructure, are surfaced explicitly with the tradeoffs of each option. Users choose a priority or request research into alternatives that might satisfy both needs.

The completed spec is written as a markdown file to thoughts/shared/specs/ with a date-prefixed filename. It includes the problem statement, user journeys, functional requirements, technical architecture, and acceptance criteria.

Skip it for trivial scripts or well-understood tasks where requirements are already clear. The process is designed for non-trivial projects and enforces minimum question counts, so it adds overhead when the scope is already fully defined.