msd-core/get-shit-done/references/questioning.md

<questioning_guide> 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.

<conversation_arc> 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?" </conversation_arc>

<good_vs_bad> 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 </good_vs_bad>

<probing_techniques> 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. </probing_techniques>

<coverage_check> 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. </coverage_check>

<decision_gate> When you feel you understand the vision, offer the choice:

Header: "Ready?"
Question: "Ready to create PROJECT.md, or explore more?"
Options (ALL THREE REQUIRED):
  1. "Create PROJECT.md" - Finalize and continue
  2. "Ask more questions" - I'll dig into areas we haven't covered
  3. "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. </decision_gate>

<anti_patterns>

• 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 </anti_patterns> </questioning_guide>