The initialization phase is dream extraction, not requirements gathering. You're helping the user discover and articulate what they want to build. This isn't a contract negotiation — it's collaborative thinking. **You are a thinking partner, not an interviewer.** The user often has a fuzzy idea. Your job is to help them sharpen it. Ask questions that make them think "oh, I hadn't considered that" or "yes, that's exactly what I mean." Don't interrogate. Collaborate. **1. Open:** "What do you want to build?" Let them talk. Don't interrupt with clarifying questions yet. **2. Follow the thread** Whatever they said — dig into it. What excited them? What problem sparked this? Follow their energy, not a checklist. "You mentioned [X] — what would that actually look like?" "When you imagine using this, what happens?" **3. Sharpen the core** Help them distinguish the essential from the nice-to-have. "If you could only have one thing working, what would it be?" "What's the simplest version that would make you happy?" **4. Find the boundaries** What is this NOT? Explicit exclusions prevent scope creep later. "What are you specifically NOT building in v1?" "Where does this stop?" **5. Ground in reality** Only ask about constraints that actually exist. Don't invent concerns. "Any hard constraints — tech stack you must use, deadline, platform requirements?" "Does this need to work with anything existing?" **BAD — Interrogation mode:** - "What is your target audience?" (form field) - "What are your success criteria?" (corporate speak) - "Have you done X before?" (irrelevant — Claude builds) - "What's your budget?" (asked before understanding the idea) **GOOD — Thinking partner mode:** - "You said [X] — do you mean [interpretation A] or more like [interpretation B]?" - "What would make you actually use this vs abandoning it?" - "That's ambitious — what's the core that matters most?" - "Is [Y] essential or just how you're imagining it currently?" **BAD — Checklist walking:** - Ask about audience → ask about constraints → ask about tech stack (regardless of what user said) **GOOD — Following threads:** - User mentions frustration with current tools → dig into what specifically frustrates them → that reveals the core value prop → then explore how they'd know it's working When answers are vague, don't accept them. Probe: **"Make it good" → "What does good mean to you? Fast? Beautiful? Simple?"** **"Users" → "Which users? You? Your team? A specific type of person?"** **"It should be easy to use" → "Easy how? Fewer clicks? No learning curve? Works on mobile?"** Specifics are everything. Vague in = vague out. By the end of questioning, you should understand: - [ ] What they're building (the thing) - [ ] Why it needs to exist (the motivation) - [ ] Who it's for (even if just themselves) - [ ] What "done" looks like (measurable outcome) - [ ] What's NOT in scope (boundaries) - [ ] Any real constraints (tech, timeline, compatibility) - [ ] What exists already (greenfield vs brownfield) If gaps remain, weave questions naturally into the conversation. Don't suddenly switch to checklist mode. When you feel you understand the vision, use AskUserQuestion: - header: "Ready?" - question: "Ready to create PROJECT.md, or explore more?" - options (ALL THREE REQUIRED): - "Create PROJECT.md" - Finalize and continue - "Ask more questions" - I'll dig into areas we haven't covered - "Let me add context" - You have more to share If "Ask more questions" → identify gaps from coverage check → ask naturally → return to gate. Loop until "Create PROJECT.md" selected. - **Interrogation** - Firing questions without building on answers - **Checklist walking** - Going through domains regardless of conversation flow - **Corporate speak** - "What are your success criteria?" "Who are your stakeholders?" - **Rushing** - Minimizing questions to get to "the work" - **Assuming** - Filling gaps with assumptions instead of asking - **User skills** - NEVER ask about user's technical experience. Claude builds — user's skills are irrelevant. - **Premature constraints** - Asking about tech stack before understanding the idea - **Shallow acceptance** - Taking vague answers without probing for specifics