feat(docs): low-friction decision prompts + modernize tool name in collaborative principle

Bridged from Codex Game Studios commit 687320f.

- Adds 'no clickable UI' fallback guidance with numbered/a.yes-b.no
  shortcuts when the question tool is unavailable.
- Updates Explain->Capture, When to Use, Format Guidelines, and the
  For Agents block to list real viable options and use a.yes/b.no for
  confirmations.
- Modernizes AskUserQuestion -> question across the whole file (the
  original port only renamed tools in agent/skill bodies, leaving this
  doc on the Claude tool name). 10 occurrences updated.

Adapted Codex -> OpenCode: numbered choice prompt -> question.

Author: Cipher-85

docs/COLLABORATIVE-DESIGN-PRINCIPLE.md

@@ -329,12 +329,25 @@ Skill: "Writing design/concept.md..."
 
 ---
 
-## 🎛️ Structured Decision UI (AskUserQuestion)
+## 🎛️ Structured Decision UI (question)
 
-Use the `AskUserQuestion` tool to present decisions as a **selectable UI** instead
+Use the `question` tool to present decisions as a **selectable UI** instead
 of plain markdown text. This gives the user a clean interface to pick from options
 (or type "Other" for a custom answer).
 
+OpenCode surfaces may not always provide that clickable UI. When the tool is not
+available, use the same structure as compact plain text so the user can answer
+with a short token:
+
+- Multiple viable options: `1.`, `2.`, `3.` with one `(Recommended)` option.
+- Yes/no confirmations:
+  - `a. yes`
+  - `b. no`
+- List all real viable options, usually 3-5 when available and fewer when fewer
+  are viable. Do not invent filler options.
+- Never end with an unstructured "what do you want to do?" when a small viable
+  choice set is possible.
+
 ### The Explain → Capture Pattern
 
 Detailed reasoning doesn't fit in the tool's short descriptions. So use a two-step
@@ -344,13 +357,15 @@ pattern:
    detailed pros/cons, theory references, example games, pillar alignment. This is
    where the reasoning lives.
 
-2. **Capture the decision** — Call `AskUserQuestion` with concise option labels
-   and short descriptions. The user picks from the UI or types a custom answer.
+2. **Capture the decision** — Call `question` with concise option labels
+   and short descriptions when available; otherwise present the same options as
+   compact numbered text. The user picks from the UI, types a short token, or
+   types a custom answer.
 
-### When to Use AskUserQuestion
+### When to Use question
 
 ✅ **Use it for:**
-- Every decision point where you'd present 2-4 options
+- Every decision point where you'd present a small set of real viable options
 - Initial clarifying questions with constrained answers
 - Batching up to 4 independent questions in one call
 - Next-step choices ("Draft formulas or refine rules first?")
@@ -359,14 +374,17 @@ pattern:
 
 ❌ **Don't use it for:**
 - Open-ended discovery questions ("What excites you about roguelikes?")
-- Single yes/no confirmations ("May I write to file?")
+- Single yes/no confirmations ("May I write to file?") - use `a. yes` /
+  `b. no` instead when a shortcut helps.
 - When running as a Task subagent (tool may not be available)
 
 ### Format Guidelines
 
 - **Labels**: 1-5 words (e.g., "Hybrid Discovery", "Full Randomized")
 - **Descriptions**: 1 sentence summarizing the approach and key trade-off
 - **Recommended**: Add "(Recommended)" to your preferred option's label
+- **Fallback**: If no selectable UI is available, preserve the same choices as
+  numbered or lettered plain text.
 - **Previews**: Use `markdown` field for comparing code structures or formulas
 - **Multi-select**: Use `multiSelect: true` when choices aren't mutually exclusive
 
@@ -375,7 +393,7 @@ pattern:
 After introducing the topic in conversation, batch constrained questions:
 
 ```
-AskUserQuestion:
+question:
   questions:
     - question: "Should crafting recipes be discovered or learned?"
       header: "Discovery"
@@ -402,7 +420,7 @@ AskUserQuestion:
 After writing the full pros/cons analysis in conversation text:
 
 ```
-AskUserQuestion:
+question:
   questions:
     - question: "Which crafting approach fits your vision?"
       header: "Approach"
@@ -420,7 +438,7 @@ AskUserQuestion:
 After presenting the full strategic analysis with pillar alignment:
 
 ```
-AskUserQuestion:
+question:
   questions:
     - question: "How should we handle crafting scope for Alpha?"
       header: "Scope"
@@ -436,12 +454,12 @@ AskUserQuestion:
 ### Team Skill Orchestration
 
 In team skills, subagents return their analysis as text. The **orchestrator**
-(main session) calls `AskUserQuestion` at each decision point between phases:
+(main session) calls `question` at each decision point between phases:
 
 ```
 [game-designer returns 3 combat approaches with analysis]
 
-Orchestrator uses AskUserQuestion:
+Orchestrator uses question:
   question: "Which combat approach should we develop?"
   options: [concise summaries of the 3 approaches]
 
@@ -658,15 +676,15 @@ BEFORE proposing solutions:
 3. Gather context about user's vision and constraints
 
 WHEN proposing solutions:
-1. Present 2-4 options (not just one)
+1. Present the real viable options, usually 3-5 and fewer when fewer are viable
 2. Explain trade-offs for each
 3. Reference game design theory, user's pillars, or comparable games
 4. Make a recommendation but defer final decision to user
 
 BEFORE writing files:
 1. Show draft or summary
 2. Explicitly ask: "May I write this to [file]?"
-3. Wait for "yes"
+3. Offer `a. yes` / `b. no` and wait for approval
 
 WHEN implementing:
 1. Explain architectural choices
@@ -685,4 +703,4 @@ This principle has been fully embedded across the project:
 - **All skills** — Updated to require approval before writing
 - **WORKFLOW-GUIDE.md** — Rewritten with collaborative examples
 - **README.md** — Clarifies collaborative (not autonomous) design
-- **AskUserQuestion tool** — Integrated into 16 skills for structured option UI
+- **question tool** — Integrated into 16 skills for structured option UI