From 83e27785db65ac16cca263882e5de0c1cf16d95e Mon Sep 17 00:00:00 2001 From: Lex Christopherson Date: Mon, 15 Dec 2025 22:15:02 -0600 Subject: [PATCH] feat: rewrite questioning as thinking partner, not interviewer - 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. --- commands/gsd/new-project.md | 33 ++--- get-shit-done/references/questioning.md | 185 +++++++++++------------- 2 files changed, 98 insertions(+), 120 deletions(-) diff --git a/commands/gsd/new-project.md b/commands/gsd/new-project.md index bc7eb0083..590e5f81a 100644 --- a/commands/gsd/new-project.md +++ b/commands/gsd/new-project.md @@ -7,18 +7,6 @@ allowed-tools: - AskUserQuestion --- - - Initialize a new project through comprehensive context gathering. @@ -57,21 +45,25 @@ Silent setup - execute before any user output: Start: "What do you want to build?" -Then use AskUserQuestion to cover the 9 domains (project type, problem, audience, success, constraints, scope, current state, decisions, open questions). +Let them talk. Then follow the conversation arc from `questioning.md`: +1. **Follow the thread** — dig into what they said, what excites them +2. **Sharpen the core** — essential vs nice-to-have +3. **Find boundaries** — what is it NOT +4. **Ground in reality** — only constraints that actually exist -Skip domains already clear from user input. Probe for specifics on vague answers. +Be a thinking partner, not an interviewer. Help them discover and articulate their vision. -**Decision gate (MUST have all 3 options):** +When you feel you understand it, offer the decision gate: ``` Header: "Ready?" Options: 1. "Create PROJECT.md" - Finalize - 2. "Ask more questions" - Dig into uncovered domains + 2. "Ask more questions" - I'll dig deeper 3. "Let me add context" - User shares more ``` -If "Ask more questions" → ask about 2-3 uncovered domains → return to gate. +If "Ask more questions" → check coverage gaps from `questioning.md` → ask naturally → return to gate. Loop until "Create PROJECT.md" selected. @@ -95,7 +87,6 @@ Use AskUserQuestion: Create `.planning/config.json` with chosen mode using `templates/config.json` structure. - ```bash git add .planning/PROJECT.md .planning/config.json @@ -107,19 +98,24 @@ docs: initialize [project-name] Creates PROJECT.md with vision and requirements. EOF )" + ``` ``` + Project initialized: + - Project: .planning/PROJECT.md - Config: .planning/config.json (mode: [chosen mode]) What's next? + 1. Research domain ecosystem (/gsd:research-project) - For niche/complex domains 2. Create roadmap (/gsd:create-roadmap) - Skip research, go straight to planning 3. Done for now + ``` If user selects "Research domain ecosystem" → invoke `/gsd:research-project` @@ -139,3 +135,4 @@ If user selects "Create roadmap" → invoke `/gsd:create-roadmap` - [ ] config.json has workflow mode - [ ] All committed to git +``` diff --git a/get-shit-done/references/questioning.md b/get-shit-done/references/questioning.md index 3e8588a32..08cf7337a 100644 --- a/get-shit-done/references/questioning.md +++ b/get-shit-done/references/questioning.md @@ -1,113 +1,96 @@ -The initialization questioning phase is the most leveraged moment in any project. Context gathered here flows through every downstream decision. Don't rush it. +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. - -Ask about gaps - skip what's already clear from user input. + +**You are a thinking partner, not an interviewer.** - -What kind of thing is this? -- Product/app (software for users) -- Automation/tool (system to automate a process) -- Research/analysis (investigation or learning) -- Creative work (content, art, media) - +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." - -Why does this need to exist? -- What pain point? -- What gap in current solutions? -- What opportunity? -- What's the current state without this? - +Don't interrogate. Collaborate. + - -Who is this for? -- Just the user (personal tool) -- Their team (internal use) -- Specific user segment (targeted audience) -- General public (broad availability) - + +**1. Open:** "What do you want to build?" - -What does "done" look like? -- Must be measurable/verifiable -- Not vague ("make it good") -- Specific outcomes, not activities - +Let them talk. Don't interrupt with clarifying questions yet. - -What limits exist? -- Tech stack (must use X, can't use Y) -- Timeline (deadline, urgency) -- Resources (budget, team size) -- Dependencies (needs X to exist first) -- Compatibility (must work with Y) - +**2. Follow the thread** - -What are you NOT building? -- Explicit exclusions prevent creep -- "Not in v1" is valid -- Helps focus on what matters - +Whatever they said — dig into it. What excited them? What problem sparked this? Follow their energy, not a checklist. - -What exists already? -- Greenfield (nothing exists) -- Brownfield (existing code/system) -- Prior attempts (what was tried, what failed) -- Related work (adjacent systems) - +"You mentioned [X] — what would that actually look like?" +"When you imagine using this, what happens?" - -Any already made? -- Framework choices -- Architecture patterns -- Key libraries -- Deployment target - +**3. Sharpen the core** - -What's still unclear? -- Known unknowns -- Decisions deferred -- Areas needing research - - +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?" - -Every follow-up question uses structured options: -- 2-4 choices per question -- Always include "Other" or "Let me explain" -- Options should be mutually exclusive when possible - +**4. Find the boundaries** - -After receiving answers, evaluate completeness: +What is this NOT? Explicit exclusions prevent scope creep later. -**Critical gaps exist:** -- State the gap clearly -- Ask about it immediately -- Don't offer to finalize yet +"What are you specifically NOT building in v1?" +"Where does this stop?" -**Sufficient context:** -- Acknowledge what's gathered -- Note optional areas could explore -- Offer choice: finalize or dig deeper +**5. Ground in reality** -**Comprehensive:** -- Acknowledge depth -- Offer to finalize -- Only edge cases remain - +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?" + -**CRITICAL: Always present ALL THREE options. Never skip "Ask more questions".** + +**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) -Use AskUserQuestion with exactly these options: +**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, offer the choice: ``` Header: "Ready?" @@ -118,21 +101,19 @@ Options (ALL THREE REQUIRED): 3. "Let me add context" - You have more to share ``` -If user selects "Ask more questions": -- Identify domains not yet covered from the 9 domains list -- Ask about 2-3 of them -- Return to decision gate +If "Ask more questions" → identify gaps from coverage check → ask naturally → return to gate. Loop until "Create PROJECT.md" selected. - - + - -- **Rushing** - Don't minimize questions to get to "the work" -- **Assuming** - Don't fill gaps with assumptions, ask -- **Leading** - Don't push toward a preferred answer -- **Repeating** - Don't ask about what user already provided -- **Shallow** - Don't accept vague answers, probe for specifics +- **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