spec-interview

The goal is to surface hidden assumptions and force decisions BEFORE implementation begins.

<essential_principles>

</essential_principles>

<quick_start>

1. Check if SPEC.md exists and read it
2. Identify gaps, ambiguities, and untested assumptions
3. Begin interviewing using AskUserQuestionTool
4. Cover ALL domains systematically (see question_domains)
5. Write completed spec to SPEC.md </quick_start>

If exists: Analyze what’s defined vs. what’s missing or vague. If not: Start fresh, but ask about existing context (related systems, constraints, prior art).

CRITICAL: Each question must:

• Be specific to THIS project (not generic)
• Surface a decision or assumption
• Have meaningful, distinct options
• Force the user to commit to something

Probe these immediately before moving on.

<question_domains>

</question_domains>

<interview_techniques>

</interview_techniques>

<success_criteria> Interview is complete when:

• All domains have been covered with project-specific questions
• User has made explicit decisions on all tradeoffs
• No “TBD” or “we’ll figure it out” remains in critical areas
• Edge cases and failure modes have concrete handling strategies
• The spec could be handed to a developer who would know what to build
• User confirms “this is complete enough to start building” </success_criteria>

<spec_template_location> See templates/spec-template.md for the output structure. </spec_template_location>