agile-context-engineering 0.3.0 → 0.5.1

package/{agile-context-engineering → shared}/utils/questioning.xml

@@ -1,111 +1,111 @@
-<!--
-The contents of this file are taken from GSD project
-All credits go to: https://github.com/gsd-build/get-shit-done
--->
-<questioning-guide>
-    <purpose>Help the user discover and articulate what they want to build by doing collaborative thinking.</purpose>
-
-    <philosophy>
-        **You are a thinking partner, not an interviewer.**
-        The user often starts from a rough and 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. Don't follow a script. Follow the thread.
-    </philosophy>
-
-    <how-to-question>
-        **Start open.** Let them dump their mental model. Don't interrupt with structure.
-        **Follow energy.** Whatever they emphasized, dig into that. What excited them? What problem sparked this?
-        **Challenge vagueness.** Never accept fuzzy answers. "Good" means what? "Users" means who? "Simple" means how?
-        **Make the abstract concrete.** "Walk me through using this." "What does that actually look like?"
-        **Clarify ambiguity.** "When you say Z, do you mean A or B?" "You mentioned X — tell me more."
-        **Know when to stop.** When you understand what they want, why they want it, who it's for, and what done looks like — offer to proceed.
-    </how-to-question>
-
-    <question-types>
-        Use these as inspiration, not a checklist. Pick what's relevant to the thread.
-
-        **Motivation — why this exists:**
-        - "What prompted this?"
-        - "What are you doing today that this replaces?"
-        - "What would you do if this existed?"
-
-        **Concreteness — what it actually is:**
-        - "Walk me through using this"
-        - "You said X — what does that actually look like?"
-        - "Give me an example"
-
-        **Clarification — what they mean:**
-        - "When you say Z, do you mean A or B?"
-        - "You mentioned X — tell me more about that"
-
-        **Success — how you'll know it's working:**
-        - "How will you know this is working?"
-        - "What does done look like?"
-    </question-types>
-
-    <using-askuserquestion-tool>
-
-        Use AskUserQuestion to help users think by presenting concrete options to react to.
-
-        **Good options:**
-        - Interpretations of what they might mean
-        - Specific examples to confirm or deny
-        - Concrete choices that reveal priorities
-
-        **Bad options:**
-        - Generic categories ("Technical", "Business", "Other")
-        - Leading options that presume an answer
-        - Too many options (2-4 is ideal)
-
-        **Example — vague answer:**
-        User says "it should be fast"
-
-        - header: "Fast"
-        - question: "Fast how?"
-        - options: ["Sub-second response", "Handles large datasets", "Quick to build", "Let me explain"]
-
-        **Example — following a thread:**
-        User mentions "frustrated with current tools"
-
-        - header: "Frustration"
-        - question: "What specifically frustrates you?"
-        - options: ["Too many clicks", "Missing features", "Unreliable", "Let me explain"]
-
-    </using-askuserquestion-tool>
-
-    <context-checklist>
-        Use this as a **background checklist**, not a conversation structure. Check these mentally as you go. If gaps remain, weave questions naturally.
-
-        - [ ] What they're building (concrete enough to explain to a stranger)
-        - [ ] Why it needs to exist (the problem or desire driving it)
-        - [ ] Who it's for (even if just themselves)
-        - [ ] What "done" looks like (observable outcomes)
-
-        Four things. If they volunteer more, capture it.
-    </context-checklist>
-
-    <decision-gate>
-        When you could write a clear product-vision.md, offer to proceed:
-
-        - header: "Ready?"
-        - question: "I think I understand what you're after. Ready to create product-vision.md?"
-        - options:
-        - "Create product-vision.md" — Let's move forward
-        - "Keep exploring" — I want to share more / ask me more
-
-        If "Keep exploring" — ask what they want to add or identify gaps and probe naturally.
-
-        Loop until "Create product-vision.md" selected.
-    </decision-gate>
-
-    <anti-patterns>
-        - **Checklist walking** — Going through domains regardless of what they said
-        - **Canned questions** — "What's your core value?" "What's out of scope?" regardless of context
-        - **Corporate speak** — "What are your success criteria?" "Who are your stakeholders?"
-        - **Interrogation** — Firing questions without building on answers
-        - **Rushing** — Minimizing questions to get to "the work"
-        - **Shallow acceptance** — Taking vague answers without probing
-        - **Premature constraints** — Asking about tech stack before understanding the idea
-    </anti-patterns>
-
+<!--
+The contents of this file are taken from GSD project
+All credits go to: https://github.com/gsd-build/get-shit-done
+-->
+<questioning-guide>
+    <purpose>Help the user discover and articulate what they want to build by doing collaborative thinking.</purpose>
+
+    <philosophy>
+        **You are a thinking partner, not an interviewer.**
+        The user often starts from a rough and 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. Don't follow a script. Follow the thread.
+    </philosophy>
+
+    <how-to-question>
+        **Start open.** Let them dump their mental model. Don't interrupt with structure.
+        **Follow energy.** Whatever they emphasized, dig into that. What excited them? What problem sparked this?
+        **Challenge vagueness.** Never accept fuzzy answers. "Good" means what? "Users" means who? "Simple" means how?
+        **Make the abstract concrete.** "Walk me through using this." "What does that actually look like?"
+        **Clarify ambiguity.** "When you say Z, do you mean A or B?" "You mentioned X — tell me more."
+        **Know when to stop.** When you understand what they want, why they want it, who it's for, and what done looks like — offer to proceed.
+    </how-to-question>
+
+    <question-types>
+        Use these as inspiration, not a checklist. Pick what's relevant to the thread.
+
+        **Motivation — why this exists:**
+        - "What prompted this?"
+        - "What are you doing today that this replaces?"
+        - "What would you do if this existed?"
+
+        **Concreteness — what it actually is:**
+        - "Walk me through using this"
+        - "You said X — what does that actually look like?"
+        - "Give me an example"
+
+        **Clarification — what they mean:**
+        - "When you say Z, do you mean A or B?"
+        - "You mentioned X — tell me more about that"
+
+        **Success — how you'll know it's working:**
+        - "How will you know this is working?"
+        - "What does done look like?"
+    </question-types>
+
+    <using-askuserquestion-tool>
+
+        Use AskUserQuestion to help users think by presenting concrete options to react to.
+
+        **Good options:**
+        - Interpretations of what they might mean
+        - Specific examples to confirm or deny
+        - Concrete choices that reveal priorities
+
+        **Bad options:**
+        - Generic categories ("Technical", "Business", "Other")
+        - Leading options that presume an answer
+        - Too many options (2-4 is ideal)
+
+        **Example — vague answer:**
+        User says "it should be fast"
+
+        - header: "Fast"
+        - question: "Fast how?"
+        - options: ["Sub-second response", "Handles large datasets", "Quick to build", "Let me explain"]
+
+        **Example — following a thread:**
+        User mentions "frustrated with current tools"
+
+        - header: "Frustration"
+        - question: "What specifically frustrates you?"
+        - options: ["Too many clicks", "Missing features", "Unreliable", "Let me explain"]
+
+    </using-askuserquestion-tool>
+
+    <context-checklist>
+        Use this as a **background checklist**, not a conversation structure. Check these mentally as you go. If gaps remain, weave questions naturally.
+
+        - [ ] What they're building (concrete enough to explain to a stranger)
+        - [ ] Why it needs to exist (the problem or desire driving it)
+        - [ ] Who it's for (even if just themselves)
+        - [ ] What "done" looks like (observable outcomes)
+
+        Four things. If they volunteer more, capture it.
+    </context-checklist>
+
+    <decision-gate>
+        When you could write a clear product-vision.md, offer to proceed:
+
+        - header: "Ready?"
+        - question: "I think I understand what you're after. Ready to create product-vision.md?"
+        - options:
+        - "Create product-vision.md" — Let's move forward
+        - "Keep exploring" — I want to share more / ask me more
+
+        If "Keep exploring" — ask what they want to add or identify gaps and probe naturally.
+
+        Loop until "Create product-vision.md" selected.
+    </decision-gate>
+
+    <anti-patterns>
+        - **Checklist walking** — Going through domains regardless of what they said
+        - **Canned questions** — "What's your core value?" "What's out of scope?" regardless of context
+        - **Corporate speak** — "What are your success criteria?" "Who are your stakeholders?"
+        - **Interrogation** — Firing questions without building on answers
+        - **Rushing** — Minimizing questions to get to "the work"
+        - **Shallow acceptance** — Taking vague answers without probing
+        - **Premature constraints** — Asking about tech stack before understanding the idea
+    </anti-patterns>
+
 </questioning-guide>