83e27785db
- Replace interrogation-style domain checklist with conversation arc - Focus on following user's thread, not walking a checklist - Add good vs bad examples to guide natural questioning - Update new-project to use new philosophy Questioning now helps users discover and articulate their vision through collaborative thinking instead of form-filling.
120 lines
4.5 KiB
Markdown
120 lines
4.5 KiB
Markdown
<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.
|
|
|
|
<philosophy>
|
|
**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.
|
|
</philosophy>
|
|
|
|
<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>
|