diff --git a/.opencode/skills/adopt/SKILL.md b/.opencode/skills/adopt/SKILL.md index 2b7f04b..b85cb3e 100644 --- a/.opencode/skills/adopt/SKILL.md +++ b/.opencode/skills/adopt/SKILL.md @@ -3,7 +3,7 @@ name: adopt description: "Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills." argument-hint: "[focus: full | gdds | adrs | stories | infra]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, question agent: technical-director --- @@ -61,7 +61,7 @@ Use the same heuristic as `/project-stage-detect`: - game-concept.md exists → Concept - Nothing → Fresh (not a brownfield project — suggest `/start`) -If the project appears fresh (no artifacts at all), use `AskUserQuestion`: +If the project appears fresh (no artifacts at all), use `question`: - "This looks like a fresh project — no existing artifacts found. `/adopt` is for projects with work to migrate. What would you like to do?" - "Run `/start` — begin guided first-time onboarding" @@ -268,7 +268,7 @@ If a prior adoption plan was detected in Phase 1, add a note: > "A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will > reflect current project state — it does not diff against the prior run." -Use `AskUserQuestion`: +Use `question`: - "Ready to write the migration plan?" - "Yes — write `docs/adoption-plan-[date].md`" - "Show me the full plan preview first (don't write yet)" @@ -369,7 +369,7 @@ After writing the adoption plan (or if the user cancels writing), check whether **If it exists**: Read it and note the current mode — "Review mode is already set to `[current]`." — skip the prompt. -**If it does not exist**: Use `AskUserQuestion`: +**If it does not exist**: Use `question`: - **Prompt**: "One more setup step: how much design review would you like as you work through the workflow?" - **Options**: @@ -389,11 +389,11 @@ Create the `production/` directory if it does not exist. ## Phase 7: Offer First Action After writing the plan, don't stop there. Pick the single highest-priority gap -and offer to handle it immediately using `AskUserQuestion`. Choose the first +and offer to handle it immediately using `question`. Choose the first branch that applies: **If there are parenthetical status values in systems-index.md:** -Use `AskUserQuestion`: +Use `question`: - "The most urgent fix is `systems-index.md` — [N] rows have parenthetical status values (e.g. `Needs Revision (see notes)`) that break /gate-check, /create-stories, and /architecture-review right now. I can fix these in-place." @@ -402,7 +402,7 @@ Use `AskUserQuestion`: - "Done — leave me with the plan" **If ADRs are missing `## Status` (and no parenthetical issue):** -Use `AskUserQuestion`: +Use `question`: - "The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames]. Without it, /story-readiness silently passes all ADR checks. Start with [first affected filename]?" @@ -411,7 +411,7 @@ Use `AskUserQuestion`: - "I'll handle ADRs myself" **If GDDs are missing Acceptance Criteria (and no blocking issues above):** -Use `AskUserQuestion`: +Use `question`: - "The most urgent gap is missing Acceptance Criteria in [N] GDD(s): [list filenames]. Without them, /create-stories can't generate stories. Start with [highest-priority GDD filename]?" @@ -420,7 +420,7 @@ Use `AskUserQuestion`: - "I'll handle GDDs myself" **If no BLOCKING or HIGH gaps exist:** -Use `AskUserQuestion`: +Use `question`: - "No blocking gaps — this project is template-compatible. What next?" - "Walk me through the medium-priority improvements" - "Run /project-stage-detect for a broader health check" diff --git a/.opencode/skills/architecture-decision/SKILL.md b/.opencode/skills/architecture-decision/SKILL.md index 0abbdc9..5da63fe 100644 --- a/.opencode/skills/architecture-decision/SKILL.md +++ b/.opencode/skills/architecture-decision/SKILL.md @@ -3,7 +3,7 @@ name: architecture-decision description: "Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR." argument-hint: "[title] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question --- When this skill is invoked: @@ -169,7 +169,7 @@ or explicitly accepted as an intentional exception. Before asking anything, derive the skill's best guesses from the context already gathered (GDDs read, engine reference loaded, existing ADRs scanned). Then present -a **confirm/adjust** prompt using `AskUserQuestion` — not open-ended questions. +a **confirm/adjust** prompt using `question` — not open-ended questions. **Derive assumptions first:** - **Problem**: Infer from the title + GDD context what decision needs to be made @@ -178,11 +178,11 @@ a **confirm/adjust** prompt using `AskUserQuestion` — not open-ended questions - **GDD linkage**: Extract which GDD systems the title directly relates to - **Status**: Always `Proposed` for new ADRs — never ask the user what the status is -**Scope of assumptions tab**: Assumptions cover only: problem framing, alternative approaches, upstream dependencies, GDD linkage, and status. Schema design questions (e.g., "How should spawn timing work?", "Should data be inline or external?") are NOT assumptions — they are design decisions belonging to a separate step after the assumptions are confirmed. Do not include schema design questions in the assumptions AskUserQuestion widget. +**Scope of assumptions tab**: Assumptions cover only: problem framing, alternative approaches, upstream dependencies, GDD linkage, and status. Schema design questions (e.g., "How should spawn timing work?", "Should data be inline or external?") are NOT assumptions — they are design decisions belonging to a separate step after the assumptions are confirmed. Do not include schema design questions in the assumptions question widget. -**After assumptions are confirmed**, if the ADR involves schema or data design choices, use a separate multi-tab `AskUserQuestion` to ask each design question independently before drafting. +**After assumptions are confirmed**, if the ADR involves schema or data design choices, use a separate multi-tab `question` to ask each design question independently before drafting. -**Present assumptions with `AskUserQuestion`:** +**Present assumptions with `question`:** ``` Here's what I'm assuming before drafting: @@ -206,7 +206,7 @@ Status: Proposed Do not generate the ADR until the user confirms assumptions or provides corrections. **After engine specialist and TD reviews return** (Step 4.5/4.6), if unresolved -decisions remain, present each one as a separate `AskUserQuestion` with the proposed +decisions remain, present each one as a separate `question` with the proposed options as choices plus a free-text escape: ``` @@ -371,7 +371,7 @@ developers reading the GDD from implementing the wrong interface. If no inconsistencies: skip this block silently. -5. **Write approval** — Use `AskUserQuestion`: +5. **Write approval** — Use `question`: If GDD sync issues were found: - "ADR draft is complete. How would you like to proceed?" @@ -414,7 +414,7 @@ Registry candidates from this ADR: **BLOCKING — do not write to `docs/registry/architecture.yaml` without explicit user approval.** -Ask using `AskUserQuestion`: +Ask using `question`: - "May I update `docs/registry/architecture.yaml` with these [N] new stances?" - Options: "Yes — update the registry", "Not yet — I want to review the candidates", "Skip registry update" @@ -425,7 +425,7 @@ changing, set the old entry to `status: superseded_by: ADR-[NNNN]` and add the n ## 7. Closing Next Steps -After the ADR is written (and registry optionally updated), close with `AskUserQuestion`. +After the ADR is written (and registry optionally updated), close with `question`. Before generating the widget: 1. Read `docs/registry/architecture.yaml` — check if any priority ADRs are still unwritten (look for ADRs flagged in technical-preferences.md or systems-index.md as prerequisites) diff --git a/.opencode/skills/architecture-review/SKILL.md b/.opencode/skills/architecture-review/SKILL.md index cea9bad..8cc5245 100644 --- a/.opencode/skills/architecture-review/SKILL.md +++ b/.opencode/skills/architecture-review/SKILL.md @@ -3,7 +3,7 @@ name: architecture-review description: "Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to ADRs, identifies coverage gaps, detects cross-ADR conflicts, verifies engine compatibility consistency across all decisions, and produces a PASS/CONCERNS/FAIL verdict. The architecture equivalent of /design-review." argument-hint: "[focus: full | coverage | consistency | engine | single-gdd path/to/gdd.md]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question agent: technical-director model: opus --- @@ -451,7 +451,7 @@ FAIL: Critical gaps (Foundation/Core layer requirements uncovered), ## Phase 8: Write and Update Traceability Index -Use `AskUserQuestion` for the write approval: +Use `question` for the write approval: - "Review complete. What would you like to write?" - [A] Write all three files (review report + traceability index + TR registry) - [B] Write review report only — `docs/architecture/architecture-review-[date].md` @@ -605,7 +605,7 @@ After completing the review and writing approved files, present: 3. **Rerun trigger**: "Re-run `/architecture-review` after each new ADR is written to verify coverage improves" -Then close with `AskUserQuestion`: +Then close with `question`: - "Architecture review complete. What would you like to do next?" - [A] Write a missing ADR — open a fresh session and run `/architecture-decision [system]` - [B] Run `/gate-check pre-production` — if all blocking gaps are resolved @@ -619,7 +619,7 @@ If any spawned agent returns BLOCKED, errors, or fails to complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" before continuing 2. **Assess dependencies**: If the blocked agent's output is required by a later phase, do not proceed past that phase without user input -3. **Offer options** via AskUserQuestion with three choices: +3. **Offer options** via question with three choices: - Skip this agent and note the gap in the final report - Retry with narrower scope (fewer GDDs, single-system focus) - Stop here and resolve the blocker first diff --git a/.opencode/skills/art-bible/SKILL.md b/.opencode/skills/art-bible/SKILL.md index 2538a4f..38f04ae 100644 --- a/.opencode/skills/art-bible/SKILL.md +++ b/.opencode/skills/art-bible/SKILL.md @@ -3,7 +3,7 @@ name: art-bible description: "Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /brainstorm is approved and before /map-systems or any GDD authoring begins." argument-hint: "[--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question --- ## Phase 0: Parse Arguments and Context Check @@ -58,7 +58,7 @@ Read `.opencode/docs/technical-preferences.md` if it exists — extract performa Present the session context and ask two questions before authoring anything: -Use `AskUserQuestion` with two tabs: +Use `question` with two tabs: - Tab **"Scope"** — "Which sections need to be authored today?" Options: `Full bible — all 9 sections` / `Visual identity core (sections 1–4 only)` / `Asset standards only (section 8)` / `Resume — fill in missing sections` - Tab **"References"** — "Do you have reference games, films, or art that define the visual direction?" @@ -86,7 +86,7 @@ If a visual anchor exists from game-concept.md: present it and ask: - Provide: game concept (elevator pitch, core fantasy), full pillar set, platform target, any reference games/art from Phase 1 framing, the visual anchor if it exists - Ask: "Draft a Visual Identity Statement for this game. Provide: (1) a one-line visual rule that could resolve any visual decision ambiguity, (2) 2–3 supporting visual principles, each with a one-sentence design test ('when X is ambiguous, this principle says choose Y'). Anchor all principles directly in the stated pillars — each principle must serve a specific pillar." -Present the art-director's draft to the user. Use `AskUserQuestion`: +Present the art-director's draft to the user. Use `question`: - Options: `[A] Lock this in` / `[B] Revise the one-liner` / `[C] Revise a supporting principle` / `[D] Describe my own direction` Write the approved section to file immediately. @@ -158,7 +158,7 @@ Write the approved section to file. - **`art-director`**: Visual style for UI — diegetic vs. screen-space HUD, typography direction (font personality, weight, size hierarchy), iconography style (flat/outlined/illustrated/photorealistic), animation feel for UI elements - **`ux-designer`**: UX alignment check — does the visual direction support the interaction patterns this game requires? Flag any conflicts between art direction and readability/accessibility needs. -Collect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use `AskUserQuestion` to let the user decide. +Collect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use `question` to let the user decide. Write the approved section to file. @@ -209,7 +209,7 @@ Before presenting next steps, check project state: - Does `design/gdd/gdd-cross-review-*.md` exist? → review-all-gdds is done - Do GDDs exist (check above)? → include /consistency-check option -Use `AskUserQuestion` for next steps. Only include options that are genuinely next based on the state check above: +Use `question` for next steps. Only include options that are genuinely next based on the state check above: **Option pool — include only if not already done:** - `[_] Run /map-systems — decompose the concept into systems before writing GDDs` (skip if systems-index.md exists) diff --git a/.opencode/skills/asset-spec/SKILL.md b/.opencode/skills/asset-spec/SKILL.md index d165dfb..24fa39f 100644 --- a/.opencode/skills/asset-spec/SKILL.md +++ b/.opencode/skills/asset-spec/SKILL.md @@ -3,11 +3,11 @@ name: asset-spec description: "Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles. Produces structured spec files and updates the master asset manifest. Run after art bible and GDD/level design are approved, before production begins." argument-hint: "[system: | level: | character:] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question --- If no argument is provided, check whether `design/assets/asset-manifest.md` exists: -- If it exists: read it, find the first context (system/level/character) with any asset at status "Needed" but no spec file written yet, and use `AskUserQuestion`: +- If it exists: read it, find the first context (system/level/character) with any asset at status "Needed" but no spec file written yet, and use `question`: - Prompt: "The next unspecced context is **[target]**. Generate asset specs for it?" - Options: `[A] Yes — spec [target]` / `[B] Pick a different target` / `[C] Stop here` - If no manifest: fail with: @@ -45,7 +45,7 @@ Read all source material **before** asking the user anything. ### Source doc reads (by target type): - **system**: Read `design/gdd/[target-name].md`. Extract the **Visual/Audio Requirements** section. If it doesn't exist or reads `[To be designed]`: > "The Visual/Audio section of `design/gdd/[target-name].md` is empty. Either run `/design-system [target-name]` to complete the GDD, or describe the visual needs manually." - Use `AskUserQuestion`: `[A] Describe needs manually` / `[B] Stop — complete the GDD first` + Use `question`: `[A] Describe needs manually` / `[B] Stop — complete the GDD first` - **level**: Read `design/levels/[target-name].md`. Extract art requirements, asset list, VFX needs, and the art-director's production concept specs from Step 4. - **character**: Read `design/narrative/characters/[target-name].md` or search `design/narrative/` for the character profile. Extract visual description, role, and any specified distinguishing features. @@ -80,7 +80,7 @@ Group assets into categories: - **Audio** — SFX, music tracks, ambient loops *(note: audio specs are descriptions only — no generation prompts)* - **3D Assets** — meshes, materials (if applicable per engine) -Present the full identified list to the user. Use `AskUserQuestion`: +Present the full identified list to the user. Use `question`: - Prompt: "I identified [N] assets across [N] categories for **[target]**. Review before speccing:" - Show the grouped list in conversation text first - Options: `[A] Proceed — spec all of these` / `[B] Remove some assets` / `[C] Add assets I didn't catch` / `[D] Adjust categories` @@ -140,7 +140,7 @@ Combine the agent outputs into a draft spec per asset. Present all specs in conv **Status:** Needed ``` -After presenting all specs, use `AskUserQuestion`: +After presenting all specs, use `question`: - Prompt: "Asset specs for **[target]** — [N] assets. Review complete?" - Options: `[A] Approve all — write to file` / `[B] Revise a specific asset` / `[C] Regenerate with different direction` @@ -196,7 +196,7 @@ Ask: "May I update `design/assets/asset-manifest.md`?" ## Phase 6: Close -Use `AskUserQuestion`: +Use `question`: - Prompt: "Asset specs complete for **[target]**. What's next?" - Options: - `[A] Spec another system — /asset-spec system:[next-system]` diff --git a/.opencode/skills/brainstorm/SKILL.md b/.opencode/skills/brainstorm/SKILL.md index 6742160..3567934 100644 --- a/.opencode/skills/brainstorm/SKILL.md +++ b/.opencode/skills/brainstorm/SKILL.md @@ -3,7 +3,7 @@ name: brainstorm description: "Guided game concept ideation — from zero idea to a structured game concept document. Uses professional studio ideation techniques, player psychology frameworks, and structured creative exploration." argument-hint: "[genre or theme hint, or 'open'] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, webfetch, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, webfetch, Task, question --- When this skill is invoked: @@ -26,13 +26,13 @@ When this skill is invoked: exploration** where the AI acts as a creative facilitator, not a replacement for the human's vision. - **Use `AskUserQuestion`** at key decision points throughout brainstorming: + **Use `question`** at key decision points throughout brainstorming: - Constrained taste questions (genre preferences, scope, team size) - Concept selection ("Which 2-3 concepts resonate?") after presenting options - Direction choices ("Develop further, explore more, or prototype?") - Pillar ranking after concepts are refined Write full creative analysis in conversation text first, then use - `AskUserQuestion` to capture the decision with concise labels. + `question` to capture the decision with concise labels. Professional studio brainstorming principles to follow: - Withhold judgment — no idea is bad during exploration @@ -57,13 +57,13 @@ conversationally (not as a checklist): **Taste profile**: - What 3 games have you spent the most time with? What kept you coming back? *(Ask this as plain text — the user must be able to type specific game names freely. - Do NOT put this in an AskUserQuestion with preset options.)* + Do NOT put this in an question with preset options.)* - Are there genres you love? Genres you avoid? Why? - Do you prefer games that challenge you, relax you, tell you stories, - or let you express yourself? *(Use `AskUserQuestion` for this — constrained choice.)* + or let you express yourself? *(Use `question` for this — constrained choice.)* **Practical constraints** (shape the sandbox before brainstorming). -Bundle these into a single multi-tab `AskUserQuestion` with these exact tab labels: +Bundle these into a single multi-tab `question` with these exact tab labels: - Tab "Experience" — "What kind of experience do you most want players to have?" (Challenge & Mastery / Story & Discovery / Expression & Creativity / Relaxation & Flow) - Tab "Timeline" — "What's your realistic development timeline?" (Weeks / Months / 1-2 years / Multi-year) - Tab "Dev level" — "Where are you in your dev journey?" (First game / Shipped before / Professional background) @@ -106,12 +106,12 @@ For each concept, present: - **Why It Could Work** (1 sentence on market/audience fit) - **Biggest Risk** (1 sentence on the hardest unanswered question) -Present all three. Then use `AskUserQuestion` to capture the selection. +Present all three. Then use `question` to capture the selection. **CRITICAL**: This MUST be a plain list call — no tabs, no form fields. Use exactly this structure: ``` -AskUserQuestion( +question( prompt: "Which concept resonates with you? You can pick one, combine elements, or ask for fresh directions.", options: [ "Concept 1 — [Title]", @@ -137,7 +137,7 @@ isolation, no amount of content or polish will save the game. **30-Second Loop** (moment-to-moment): -Ask these as `AskUserQuestion` calls — derive the options from the chosen concept, don't hardcode them: +Ask these as `question` calls — derive the options from the chosen concept, don't hardcode them: 1. **Core action feel** — prompt: "What's the primary feel of the core action?" Generate 3-4 options that fit the concept's genre and tone, plus a free-text escape (`I'll describe it`). @@ -186,11 +186,11 @@ Then define **3+ anti-pillars** (what this game is NOT): be cool if..." features that don't serve the core vision - Frame as: "We will NOT do [thing] because it would compromise [pillar]" -**Pillar confirmation**: After presenting the full pillar set, use `AskUserQuestion`: +**Pillar confirmation**: After presenting the full pillar set, use `question`: - Prompt: "Do these pillars feel right for your game?" - Options: `[A] Lock these in` / `[B] Rename or reframe one` / `[C] Swap a pillar out` / `[D] Something else` -If the user selects B, C, or D, make the revision, then use `AskUserQuestion` again: +If the user selects B, C, or D, make the revision, then use `question` again: - Prompt: "Pillars updated. Ready to lock these in?" - Options: `[A] Lock these in` / `[B] Revise another pillar` / `[C] Something else` @@ -209,7 +209,7 @@ Repeat until the user selects [A] Lock these in. - **`art-director`** — gate **AD-CONCEPT-VISUAL** (`.opencode/docs/director-gates.md`) Pass: game concept elevator pitch, full pillar set with design tests, target platform (if known), any reference games or visual touchstones the user mentioned. -Collect both verdicts, then present them together using a two-tab `AskUserQuestion`: +Collect both verdicts, then present them together using a two-tab `question`: - Tab **"Pillars"**: present creative-director feedback. Options mirror the standard CD-PILLARS handling — `Lock in as-is` / `Revise [specific pillar]` / `Discuss further`. - Tab **"Visual anchor"**: present the art-director's 2-3 named visual direction options. Options: each named direction (one per option) + `Combine elements across directions` + `Describe my own direction`. @@ -238,12 +238,12 @@ who this game is actually for: Ground the concept in reality: -- **Target platform**: Use `AskUserQuestion` — "What platforms are you targeting for this game?" +- **Target platform**: Use `question` — "What platforms are you targeting for this game?" Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms` Record the answer — it directly shapes the engine recommendation and will be passed to `/setup-engine`. Note platform implications if relevant (e.g., mobile means Unity is strongly preferred; console means Godot has limitations; web means Godot exports cleanly). -- **Engine experience**: Use `AskUserQuestion` — "Do you already have an engine you work in?" +- **Engine experience**: Use `question` — "Do you already have an engine you work in?" Options: `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide` - If they pick an engine → record it as their preference and move on. Do NOT second-guess it. - If "No preference" → tell them: "Run `/setup-engine` after this session — it will walk you through the full decision based on your concept and platform target." Do not make a recommendation here. @@ -292,13 +292,13 @@ Present the assessment to the user. If UNREALISTIC, offer to adjust the MVP defi This section is the seed of the art bible — it captures the "everything must move" decision before it can be forgotten between sessions. -5. Use `AskUserQuestion` for write approval: +5. Use `question` for write approval: - Prompt: "Game concept is ready. May I write it to `design/gdd/game-concept.md`?" - Options: `[A] Yes — write it` / `[B] Not yet — revise a section first` -If [B]: ask which section to revise using `AskUserQuestion` with options: `Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll describe` +If [B]: ask which section to revise using `question` with options: `Elevator Pitch` / `Core Fantasy & Unique Hook` / `Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll describe` -After revising, show the updated section as a diff or clear before/after, then use `AskUserQuestion` — "Ready to write the updated concept document?" +After revising, show the updated section as a diff or clear before/after, then use `question` — "Ready to write the updated concept document?" Options: `[A] Yes — write it` / `[B] Revise another section` Repeat until the user selects [A]. diff --git a/.opencode/skills/create-architecture/SKILL.md b/.opencode/skills/create-architecture/SKILL.md index cf2e0ac..a9e741a 100644 --- a/.opencode/skills/create-architecture/SKILL.md +++ b/.opencode/skills/create-architecture/SKILL.md @@ -3,7 +3,7 @@ name: create-architecture description: "Guided, section-by-section authoring of the master architecture document for the game. Reads all GDDs, the systems index, existing ADRs, and the engine reference library to produce a complete architecture blueprint before any code is written. Engine-version-aware: flags knowledge gaps and validates decisions against the pinned engine version." argument-hint: "[focus-area: full | layers | data-flow | api-boundaries | adr-audit] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Bash, AskUserQuestion, Task +allowed-tools: Read, Glob, Grep, Write, Bash, question, Task agent: technical-director --- @@ -352,7 +352,7 @@ Pass: architecture document path, technical requirements baseline summary, ADR l Show the Technical Director assessment and Lead Programmer verdict side by side. -Use `AskUserQuestion` — "Technical Director and Lead Programmer have reviewed the architecture. How would you like to proceed?" +Use `question` — "Technical Director and Lead Programmer have reviewed the architecture. How would you like to proceed?" Options: `Accept — proceed to handoff` / `Revise flagged items first` / `Discuss specific concerns` **Step 4 — Record sign-off in the architecture document:** diff --git a/.opencode/skills/create-control-manifest/SKILL.md b/.opencode/skills/create-control-manifest/SKILL.md index ec067af..1f7c63e 100644 --- a/.opencode/skills/create-control-manifest/SKILL.md +++ b/.opencode/skills/create-control-manifest/SKILL.md @@ -135,7 +135,7 @@ The technical-director reviews whether: Apply the verdict: - **APPROVE** → proceed to Phase 5 -- **CONCERNS** → surface via `AskUserQuestion` with options: `Revise flagged rules` / `Accept and proceed` / `Discuss further` +- **CONCERNS** → surface via `question` with options: `Revise flagged rules` / `Accept and proceed` / `Discuss further` - **REJECT** → do not write the manifest; fix the flagged rules and re-present the summary --- diff --git a/.opencode/skills/create-epics/SKILL.md b/.opencode/skills/create-epics/SKILL.md index 45b902f..7d04a24 100644 --- a/.opencode/skills/create-epics/SKILL.md +++ b/.opencode/skills/create-epics/SKILL.md @@ -3,7 +3,7 @@ name: create-epics description: "Translate approved GDDs + architecture into epics — one epic per architectural module. Defines scope, governing ADRs, engine risk, and untraced requirements. Does NOT break into stories — run /create-stories [epic-slug] after each epic is created." argument-hint: "[system-name | layer: foundation|core|feature|presentation | all] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question agent: technical-director --- diff --git a/.opencode/skills/create-stories/SKILL.md b/.opencode/skills/create-stories/SKILL.md index d8d36d3..c5c2c60 100644 --- a/.opencode/skills/create-stories/SKILL.md +++ b/.opencode/skills/create-stories/SKILL.md @@ -3,7 +3,7 @@ name: create-stories description: "Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic." argument-hint: "[epic-slug | epic-path] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question agent: lead-programmer --- @@ -157,7 +157,7 @@ Story 003: [title] — Visual/Feel — ADR-NNNN [N stories total: N Logic, N Integration, N Visual/Feel, N UI, N Config/Data] ``` -Use `AskUserQuestion`: +Use `question`: - Prompt: "May I write these [N] stories to `production/epics/[epic-slug]/`?" - Options: `[A] Yes — write all [N] stories` / `[B] Not yet — I want to review or adjust first` @@ -280,7 +280,7 @@ Replace the "Stories: Not yet created" line with a populated table: ## 7. After Writing -Use `AskUserQuestion` to close with context-aware next steps: +Use `question` to close with context-aware next steps: Check: - Are there other epics in `production/epics/` without stories yet? List them. diff --git a/.opencode/skills/day-one-patch/SKILL.md b/.opencode/skills/day-one-patch/SKILL.md index 770d372..6e73226 100644 --- a/.opencode/skills/day-one-patch/SKILL.md +++ b/.opencode/skills/day-one-patch/SKILL.md @@ -3,7 +3,7 @@ name: day-one-patch description: "Prepare a day-one patch for a game launch. Scopes, prioritises, implements, and QA-gates a focused patch addressing known issues discovered after gold master but before or immediately after public launch. Treats the patch as a mini-sprint with its own QA gate and rollback plan." argument-hint: "[scope: known-bugs | cert-feedback | all]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question --- # Day-One Patch @@ -62,7 +62,7 @@ For each open bug, evaluate: ### Step 2b — Present patch scope to user -Use `AskUserQuestion`: +Use `question`: - Prompt: "Based on open bugs and cert feedback, here is the proposed day-one patch scope. Does this look right?" - Show: table of included bugs (ID, severity, description, estimated effort) - Show: table of deferred bugs (ID, severity, reason deferred) @@ -75,7 +75,7 @@ If [C]: output "No day-one patch required. Proceed to `/launch-checklist`." Stop Sum estimated effort. If total exceeds 1 day of work: > "⚠️ Patch scope is [N hours] — this exceeds a safe day-one window. Consider deferring lower-priority items to patch 1.1. A bloated day-one patch introduces more risk than it removes." -Use `AskUserQuestion` to confirm proceeding or reduce scope. +Use `question` to confirm proceeding or reduce scope. --- diff --git a/.opencode/skills/design-review/SKILL.md b/.opencode/skills/design-review/SKILL.md index cd54d29..9d1eb79 100644 --- a/.opencode/skills/design-review/SKILL.md +++ b/.opencode/skills/design-review/SKILL.md @@ -3,7 +3,7 @@ name: design-review description: "Reviews a game design document for completeness, internal consistency, implementability, and adherence to project design standards. Run this before handing a design document to programmers." argument-hint: "[path-to-design-doc] [--depth full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question --- ## Phase 0: Parse Arguments @@ -185,7 +185,7 @@ This skill is read-only — no files are written during Phase 4. ## Phase 5: Next Steps -Use `AskUserQuestion` for ALL closing interactions. Never plain text. +Use `question` for ALL closing interactions. Never plain text. **First widget — what to do next:** @@ -198,9 +198,9 @@ If NEEDS REVISION or MAJOR REVISION NEEDED, options: **If user selects [A] — Revise now:** -Work through all blocking items, asking for design decisions only where you cannot resolve the issue from the GDD and existing docs alone. Group all design-decision questions into a single multi-tab `AskUserQuestion` before making any edits — do not interrupt mid-revision for each blocker individually. +Work through all blocking items, asking for design decisions only where you cannot resolve the issue from the GDD and existing docs alone. Group all design-decision questions into a single multi-tab `question` before making any edits — do not interrupt mid-revision for each blocker individually. -After all revisions are complete, show a summary table (blocker → fix applied) and use `AskUserQuestion` for a **post-revision closing widget**: +After all revisions are complete, show a summary table (blocker → fix applied) and use `question` for a **post-revision closing widget**: - Prompt: "Revisions complete — [N] blockers resolved. What next?" - Note current context usage: if context is above ~50%, add: "(Recommended: /clear before re-review — this session has used X% context. A full re-review runs 5 agents and needs clean context.)" @@ -214,13 +214,13 @@ Never end the revision flow with plain text. Always close with this widget. **Second widget — systems index update (always show this separately):** -Use a second `AskUserQuestion`: +Use a second `question`: - Prompt: "May I update `design/gdd/systems-index.md` to mark [system] as [In Review / Approved]?" - Options: `[A] Yes — update it` / `[B] No — leave it as-is` **Third widget — review log (always offer):** -Use a third `AskUserQuestion`: +Use a third `question`: - Prompt: "May I append this review summary to `design/gdd/reviews/[doc-name]-review-log.md`? This creates a revision history so future re-reviews can track what changed." - Options: `[A] Yes — append to review log` / `[B] No — skip` @@ -238,7 +238,7 @@ Prior verdict resolved: [Yes / No / First review] **Final closing widget — always show after all file writes complete:** -Once the systems-index and review-log widgets are answered, check project state and show one final `AskUserQuestion`: +Once the systems-index and review-log widgets are answered, check project state and show one final `question`: Before building options, read: - `design/gdd/systems-index.md` — find any system with Status: In Review or NEEDS REVISION (other than the one just reviewed) diff --git a/.opencode/skills/design-system/SKILL.md b/.opencode/skills/design-system/SKILL.md index 3eafd93..ca29899 100644 --- a/.opencode/skills/design-system/SKILL.md +++ b/.opencode/skills/design-system/SKILL.md @@ -3,7 +3,7 @@ name: design-system description: "Guided, section-by-section GDD authoring for a single game system. Gathers context from existing docs, walks through each required section collaboratively, cross-references dependencies, and writes incrementally to file." argument-hint: " [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question, TodoWrite --- When this skill is invoked: @@ -20,7 +20,7 @@ See `.opencode/docs/director-gates.md` for the full check pattern. A system name or retrofit path is **required**. If missing: 1. Check if `design/gdd/systems-index.md` exists. -2. If it exists: read it, find the highest-priority system with status "Not Started" or equivalent, and use `AskUserQuestion`: +2. If it exists: read it, find the highest-priority system with status "Not Started" or equivalent, and use `question`: - Prompt: "The next system in your design order is **[system-name]** ([priority] | [layer]). Start designing it?" - Options: `[A] Yes — design [system-name]` / `[B] Pick a different system` / `[C] Stop here` - If [A]: proceed with that system name. If [B]: ask which system to design (plain text). If [C]: exit. @@ -197,13 +197,13 @@ If no engine reference docs exist (engine not yet configured), show a short note **Step 4 — Ask before proceeding:** -Use `AskUserQuestion`: +Use `question`: - "Any constraints to add before we begin, or shall we proceed with these noted?" - Options: "Proceed with these noted", "Add a constraint first", "I need to check the engine docs — pause here" --- -Use `AskUserQuestion`: +Use `question`: - "Ready to start designing [system-name]?" - Options: "Yes, let's go", "Show me more context first", "Design a dependency first" @@ -307,12 +307,12 @@ Context -> Questions -> Options -> Decision -> Draft -> Approval -> decisions from dependency GDDs that constrain it. 2. **Questions**: Ask clarifying questions specific to this section. Use - `AskUserQuestion` for constrained questions, conversational text for open-ended + `question` for constrained questions, conversational text for open-ended exploration. 3. **Options**: Where the section involves design choices (not just documentation), present 2-4 approaches with pros/cons. Explain reasoning in conversation text, - then use `AskUserQuestion` to capture the decision. + then use `question` to capture the decision. 4. **Decision**: User picks an approach or provides custom direction. @@ -320,7 +320,7 @@ Context -> Questions -> Options -> Decision -> Draft -> Approval -> provisional assumptions about undesigned dependencies. 6. **Approval**: Immediately after the draft — in the SAME response — use - `AskUserQuestion`. **NEVER use plain text. NEVER skip this step.** + `question`. **NEVER use plain text. NEVER skip this step.** - Prompt: "Approve the [Section Name] section?" - Options: `[A] Approve — write it to file` / `[B] Make changes — describe what to fix` / `[C] Start over` @@ -370,7 +370,7 @@ Each section has unique design considerations and may benefit from specialist ag Append `(Recommended)` to the appropriate option text in each tab. -**Framing questions (ask BEFORE drafting)**: Use `AskUserQuestion` with a multi-tab widget: +**Framing questions (ask BEFORE drafting)**: Use `question` with a multi-tab widget: - Tab "Framing" — "How should the overview frame this system?" Options: `[A] As a data/infrastructure layer (technical framing)` / `[B] Through its player-facing effect (design framing)` / `[C] Both — describe the data layer and its player impact` - Tab "ADR ref" — "Should the overview reference the existing ADR for this system?" Options: `[A] Yes — cite the ADR for implementation details` / `[B] No — keep the GDD at pure design level` - Tab "Fantasy" — "Does this system have a player fantasy worth stating?" Options: `[A] Yes — players feel it directly` / `[B] No — pure infrastructure, players feel what it enables` @@ -405,7 +405,7 @@ describes the technical approach used to achieve it. Append `(Recommended)` to the appropriate option text. -**Framing question (ask BEFORE drafting)**: Use `AskUserQuestion`: +**Framing question (ask BEFORE drafting)**: Use `question`: - Prompt: "Is this system something the player engages with directly, or infrastructure they experience indirectly?" - Options: `[A] Direct — player actively uses or feels this system` / `[B] Indirect — player experiences the effects, not the system` / `[C] Both — has a direct interaction layer and infrastructure beneath it` @@ -454,7 +454,7 @@ This is usually the largest section. Break it into sub-sections: - Spawn the Primary Agent AND Supporting Agent(s) listed for this category - Provide each agent: system name, game concept summary, pillar set, dependency GDD excerpts, the specific section being worked on - Collect their findings before drafting -- Surface any disagreements between agents to the user via `AskUserQuestion` +- Surface any disagreements between agents to the user via `question` - Draft only after receiving specialist input **Do NOT draft Section C without first consulting the appropriate specialists.** A `systems-designer` reviewing rules and mechanics will catch design gaps the main session cannot. @@ -497,7 +497,7 @@ table. A formula without defined variables cannot be implemented without guesswo **Agent delegation (MANDATORY)**: Before proposing any formulas or balance values, spawn specialist agents via Task in parallel: - **Always spawn `systems-designer`**: provide Core Rules from Section C, tuning goals from user, balance context from dependency GDDs. Ask them to propose formulas with variable tables and output ranges. - **For economy/cost systems, also spawn `economy-designer`**: provide placement costs, upgrade cost intent, and progression goals. Ask them to validate cost curves and ratios. -- Present the specialists' proposals to the user for review via `AskUserQuestion` +- Present the specialists' proposals to the user for review via `question` - The user decides; the main session writes to file - **Do NOT invent formula values or balance numbers without specialist input.** A user without balance design expertise cannot evaluate raw numbers — they need the specialists' reasoning. @@ -611,7 +611,7 @@ For required systems: **spawn `art-director` via Task** before drafting this sec For **all other system categories** (Foundation/Infrastructure, Economy, AI/pathfinding, Camera/input), offer the optional sections after the required sections: -Use `AskUserQuestion`: +Use `question`: - "The 8 required sections are complete. Do you want to also define Visual/Audio requirements, UI requirements, or capture open questions?" - Options: "Yes, all three", "Just open questions", "Skip — I'll add these later" @@ -742,7 +742,7 @@ Update `production/session-state/active.md` with: ### 5e: Suggest Next Steps -Use `AskUserQuestion`: +Use `question`: - "What's next?" - Options: - "Run `/consistency-check` — verify this GDD's values don't conflict with existing GDDs (recommended before designing the next system)" @@ -778,7 +778,7 @@ orchestrates the overall flow; agents provide expert content. - Provide: system name, game concept summary, dependency GDD excerpts, the specific section being worked on, and what question needs expert input - The agent returns analysis/proposals to the main session -- The main session presents the agent's output to the user via `AskUserQuestion` +- The main session presents the agent's output to the user via `question` - The user decides; the main session writes to file - Agents do NOT write to files directly — the main session owns all file writes @@ -804,7 +804,7 @@ disruption. This skill follows the collaborative design principle at every step: 1. **Question -> Options -> Decision -> Draft -> Approval** for every section -2. **AskUserQuestion** at every decision point (Explain -> Capture pattern): +2. **question** at every decision point (Explain -> Capture pattern): - Phase 2: "Ready to start, or need more context?" - Phase 3: "May I create the skeleton?" - Phase 4 (each section): Design questions, approach options, draft approval diff --git a/.opencode/skills/dev-story/SKILL.md b/.opencode/skills/dev-story/SKILL.md index f90fa31..b01edb7 100644 --- a/.opencode/skills/dev-story/SKILL.md +++ b/.opencode/skills/dev-story/SKILL.md @@ -3,7 +3,7 @@ name: dev-story description: "Read a story file and implement it. Loads the full context (story, GDD requirement, ADR guidelines, control manifest), routes to the right programmer agent for the system and engine, implements the code and test, and confirms each acceptance criterion. The core implementation skill — run after /story-readiness, before /code-review and /story-done." argument-hint: "[story-path]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Bash, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Bash, Task, question --- # Dev Story @@ -83,7 +83,7 @@ Read `docs/architecture/control-manifest.md`. Extract the rules for this story's - Performance guardrails Check: does the story's embedded Manifest Version match the current manifest header date? -If they differ, use `AskUserQuestion` before proceeding: +If they differ, use `question` before proceeding: - Prompt: "Story was written against manifest v[story-date]. Current manifest is v[current-date]. New rules may apply. How do you want to proceed?" - Options: - `[A] Update story manifest version and implement with current rules (Recommended)` @@ -101,7 +101,7 @@ After extracting the **Dependencies** list from the story file, validate each: 1. Glob `production/epics/**/*.md` to find each dependency story file. 2. Read its `Status:` field. 3. If any dependency has Status other than `Complete` or `Done`: - - Use `AskUserQuestion`: + - Use `question`: - Prompt: "Story '[current story]' depends on '[dependency title]' which is currently [status], not Complete. How do you want to proceed?" - Options: - `[A] Proceed anyway — I accept the dependency risk` @@ -280,7 +280,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/gate-check/SKILL.md b/.opencode/skills/gate-check/SKILL.md index 6d1aa0e..437f2b1 100644 --- a/.opencode/skills/gate-check/SKILL.md +++ b/.opencode/skills/gate-check/SKILL.md @@ -3,7 +3,7 @@ name: gate-check description: "Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts. Use when user says 'are we ready to move to X', 'can we advance to production', 'check if we can start the next phase', 'pass the gate'." argument-hint: "[target-phase: systems-design | technical-setup | pre-production | production | polish | release] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Bash, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Bash, Write, Task, question model: opus --- @@ -47,7 +47,7 @@ Note: in `solo` mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GA - **No argument**: Auto-detect current stage using the same heuristics as `/project-stage-detect`, then **confirm with the user before running**: - Use `AskUserQuestion`: + Use `question`: - Prompt: "Detected stage: **[current stage]**. Running gate for [Current] → [Next] transition. Is this correct?" - Options: - `[A] Yes — run this gate` @@ -424,7 +424,7 @@ echo -n "Production" > production/stage.txt ## 7. Closing Next-Step Widget -After the verdict is presented and any stage.txt update is complete, close with a structured next-step prompt using `AskUserQuestion`. +After the verdict is presented and any stage.txt update is complete, close with a structured next-step prompt using `question`. **Tailor the options to the gate that just ran:** @@ -462,10 +462,10 @@ Based on the verdict, suggest specific next steps: - **Small design change needed?** → `/quick-design` for changes under ~4 hours (bypasses full GDD pipeline) - **No UX specs?** → `/ux-design [screen name]` to author specs, or `/team-ui [feature]` for full pipeline - **UX specs not reviewed?** → `/ux-review [file]` or `/ux-review all` to validate -- **No accessibility requirements doc?** → Use `AskUserQuestion` to offer to create it now: +- **No accessibility requirements doc?** → Use `question` to offer to create it now: - Prompt: "The gate requires `design/accessibility-requirements.md`. Shall I create it from the template?" - Options: `Create it now — I'll choose an accessibility tier`, `I'll create it myself`, `Skip for now` - - If "Create it now": use a second `AskUserQuestion` to ask for the tier: + - If "Create it now": use a second `question` to ask for the tier: - Prompt: "Which accessibility tier fits this project?" - Options: `Basic — remapping + subtitles only (lowest effort)`, `Standard — Basic + colorblind modes + scalable UI`, `Comprehensive — Standard + motor accessibility + full settings menu`, `Exemplary — Comprehensive + external audit + full customization` - Then write `design/accessibility-requirements.md` using the template at `.opencode/docs/templates/accessibility-requirements.md`, filling in the chosen tier. Confirm: "May I write `design/accessibility-requirements.md`?" diff --git a/.opencode/skills/localize/SKILL.md b/.opencode/skills/localize/SKILL.md index e43be2e..b7f8f5d 100644 --- a/.opencode/skills/localize/SKILL.md +++ b/.opencode/skills/localize/SKILL.md @@ -4,7 +4,7 @@ description: "Full localization pipeline: scan for hardcoded strings, extract an argument-hint: "[scan|extract|validate|status|brief|cultural-review|vo-pipeline|rtl-check|freeze|qa]" user-invocable: true agent: localization-lead -allowed-tools: Read, Glob, Grep, Write, Bash, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Bash, Task, question --- # Localization Pipeline @@ -331,7 +331,7 @@ Pre-Freeze Checklist [ ] Marketing strings (store description, achievements) are final ``` -Use `AskUserQuestion`: +Use `question`: - Prompt: "Are all items above confirmed? Calling string freeze locks the source table." - Options: `[A] Yes — call string freeze now` / `[B] No — I still have strings to add` diff --git a/.opencode/skills/map-systems/SKILL.md b/.opencode/skills/map-systems/SKILL.md index b139d18..6ab9108 100644 --- a/.opencode/skills/map-systems/SKILL.md +++ b/.opencode/skills/map-systems/SKILL.md @@ -3,7 +3,7 @@ name: map-systems description: "Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index." argument-hint: "[next | system-name] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite, Task +allowed-tools: Read, Glob, Grep, Write, Edit, question, TodoWrite, Task --- When this skill is invoked: @@ -44,7 +44,7 @@ for systems decomposition. **If the systems index already exists:** - Read it and present current status to the user -- Use `AskUserQuestion` to ask: +- Use `question` to ask: "The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?" - Options: "Update the index with new systems", "Design the next undesigned system", @@ -96,7 +96,7 @@ Present the enumeration organized by category. For each system, show: - Brief description (1 sentence) - Whether it was explicit (from concept) or implicit (inferred) -Then use `AskUserQuestion` to capture feedback: +Then use `question` to capture feedback: - "Are there systems missing from this list?" - "Should any of these be combined or split?" - "Are there systems listed that this game does NOT need?" @@ -141,7 +141,7 @@ Show the dependency map as a layered list. Highlight: - Any "bottleneck" systems (many others depend on them — these are high-risk) - Any systems with no dependents (leaf nodes — lower risk, can be designed late) -Use `AskUserQuestion` to ask: "Does this dependency ordering look right? Any +Use `question` to ask: "Does this dependency ordering look right? Any dependencies I'm missing or that should be removed?" **Review mode check** — apply before spawning TD-SYSTEM-BOUNDARY: @@ -175,7 +175,7 @@ Use these heuristics for initial assignment: Present the priority assignments in a table. For each tier, explain why systems were placed there. -Use `AskUserQuestion` to ask: "Do these priority assignments match your vision? +Use `question` to ask: "Do these priority assignments match your vision? Which systems should be higher or lower priority?" Explain reasoning in conversation: "I placed [system] in MVP because the core loop @@ -275,7 +275,7 @@ This phase is entered when: "Would you like to start designing individual systems now? The first system in the design order is [name]. Or would you prefer to stop here and come back later?" -Use `AskUserQuestion` for: "Start designing [system-name] now, pick a different +Use `question` for: "Start designing [system-name] now, pick a different system, or stop here?" ### Step 6b: Hand Off to /design-system @@ -297,7 +297,7 @@ The `/design-system` skill handles the full GDD authoring process: ### Step 6c: Loop or Stop -After `/design-system` completes, use `AskUserQuestion`: +After `/design-system` completes, use `question`: - "Continue to the next system ([next system name])?" - "Pick a different system?" - "Stop here for this session?" @@ -308,7 +308,7 @@ If continuing, return to Step 6a. ## Phase 7: Suggest Next Steps -After the systems index is created (or after designing some systems), present next actions using `AskUserQuestion`: +After the systems index is created (or after designing some systems), present next actions using `question`: - "Systems index is written. What would you like to do next?" - [A] Start designing GDDs — run `/design-system [first-system-in-order]` @@ -328,7 +328,7 @@ After any individual GDD is completed: This skill follows the collaborative design principle at every phase: 1. **Question -> Options -> Decision -> Draft -> Approval** at every step -2. **AskUserQuestion** at every decision point (Explain -> Capture pattern): +2. **question** at every decision point (Explain -> Capture pattern): - Phase 2: "Missing systems? Combine or split?" - Phase 3: "Dependency ordering correct?" - Phase 4: "Priority assignments match your vision?" diff --git a/.opencode/skills/milestone-review/SKILL.md b/.opencode/skills/milestone-review/SKILL.md index 161987e..5f147a7 100644 --- a/.opencode/skills/milestone-review/SKILL.md +++ b/.opencode/skills/milestone-review/SKILL.md @@ -3,7 +3,7 @@ name: milestone-review description: "Generates a comprehensive milestone progress review including feature completeness, quality metrics, risk assessment, and go/no-go recommendation. Use at milestone checkpoints or when evaluating readiness for a milestone deadline." argument-hint: "[milestone-name|current] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question --- ## Phase 0: Parse Arguments diff --git a/.opencode/skills/playtest-report/SKILL.md b/.opencode/skills/playtest-report/SKILL.md index 3afbb64..f4e2eee 100644 --- a/.opencode/skills/playtest-report/SKILL.md +++ b/.opencode/skills/playtest-report/SKILL.md @@ -3,7 +3,7 @@ name: playtest-report description: "Generates a structured playtest report template or analyzes existing playtest notes into a structured format. Use this to standardize playtest feedback collection and analysis." argument-hint: "[new|analyze path-to-notes] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question --- ## Phase 1: Parse Arguments diff --git a/.opencode/skills/propagate-design-change/SKILL.md b/.opencode/skills/propagate-design-change/SKILL.md index 8bc9da2..dc64a00 100644 --- a/.opencode/skills/propagate-design-change/SKILL.md +++ b/.opencode/skills/propagate-design-change/SKILL.md @@ -163,7 +163,7 @@ The technical-director reviews whether: Apply the verdict: - **APPROVE** → proceed to Phase 7 resolution workflow -- **CONCERNS** → surface the specific ADRs or recommendations flagged; use `AskUserQuestion` with options: `Revise the impact assessment` / `Accept with noted concerns` / `Discuss further` +- **CONCERNS** → surface the specific ADRs or recommendations flagged; use `question` with options: `Revise the impact assessment` / `Accept with noted concerns` / `Discuss further` - **REJECT** → do not proceed to resolution; re-analyze the impact before continuing --- diff --git a/.opencode/skills/qa-plan/SKILL.md b/.opencode/skills/qa-plan/SKILL.md index 25be681..2d869d4 100644 --- a/.opencode/skills/qa-plan/SKILL.md +++ b/.opencode/skills/qa-plan/SKILL.md @@ -3,7 +3,7 @@ name: qa-plan description: "Generate a QA test plan for a sprint or feature. Reads GDDs and story files, classifies stories by test type (Logic/Integration/Visual/UI), and produces a structured test plan covering automated tests required, manual test cases, smoke test scope, and playtest sign-off requirements. Run before sprint begins or when starting a major feature." argument-hint: "[sprint | feature: system-name | story: path]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, question agent: qa-lead --- @@ -25,7 +25,7 @@ plan. ## Phase 1: Parse Scope -**Argument:** `$ARGUMENTS` (blank = ask user via AskUserQuestion) +**Argument:** `$ARGUMENTS` (blank = ask user via question) Determine scope from the argument: @@ -37,7 +37,7 @@ Determine scope from the argument: to stories whose file path or title contains the system name. Also check the epic index file (`EPIC.md`) in that system's directory. - **`story: [path]`** — validate that the path exists and load that single file. -- **No argument** — use `AskUserQuestion`: +- **No argument** — use `question`: - "What is the scope for this QA plan?" - Options: "Current sprint", "Specific feature (enter system name)", "Specific story (enter path)", "Full epic" @@ -254,6 +254,6 @@ Next steps: support. If a formula is absent from the GDD, flag it rather than guessing. - **Playtest requirements are advisory**: the user decides whether a playtest is warranted for borderline Visual/Feel stories. Flag the case; do not mandate. -- Use `AskUserQuestion` for scope selection when no argument is provided. +- Use `question` for scope selection when no argument is provided. Keep all other phases non-interactive — present findings, then ask once to approve the write. diff --git a/.opencode/skills/retrospective/SKILL.md b/.opencode/skills/retrospective/SKILL.md index f404331..44fd18e 100644 --- a/.opencode/skills/retrospective/SKILL.md +++ b/.opencode/skills/retrospective/SKILL.md @@ -48,7 +48,7 @@ Read the sprint or milestone plan from the appropriate location: > "No sprint data found for [sprint/milestone]. Run `/sprint-status` to generate > sprint data first, or provide the sprint details manually." -Then use `AskUserQuestion` to present two options: +Then use `question` to present two options: - **[A] Provide data manually** — ask the user to paste or describe the sprint tasks, dates, and outcomes; use that as the source of truth for the retrospective. diff --git a/.opencode/skills/review-all-gdds/SKILL.md b/.opencode/skills/review-all-gdds/SKILL.md index dd09d62..df5db2c 100644 --- a/.opencode/skills/review-all-gdds/SKILL.md +++ b/.opencode/skills/review-all-gdds/SKILL.md @@ -3,7 +3,7 @@ name: review-all-gdds description: "Holistic cross-GDD consistency and game design review. Reads all system GDDs simultaneously and checks for contradictions between them, stale references, ownership conflicts, formula incompatibilities, and game design theory violations (dominant strategies, economic imbalance, cognitive overload, pillar drift). Run after all MVP GDDs are written, before architecture begins." argument-hint: "[focus: full | consistency | design-theory | since-last-review]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Bash, AskUserQuestion, Task +allowed-tools: Read, Glob, Grep, Write, Bash, question, Task model: opus --- @@ -544,11 +544,11 @@ FAIL: One or more blocking issues must be resolved before architecture begins. ## Phase 6: Write Report and Flag GDDs -Use `AskUserQuestion` for write permission: +Use `question` for write permission: - Prompt: "May I write this review to `design/gdd/gdd-cross-review-[date].md`?" - Options: `[A] Yes — write the report` / `[B] No — skip` -If any GDDs are flagged for revision, use a second `AskUserQuestion`: +If any GDDs are flagged for revision, use a second `question`: - Prompt: "Should I update the systems index to mark these GDDs as needing revision? ([list of flagged GDDs])" - Options: `[A] Yes — update systems index` / `[B] No — leave as-is` - If yes: update each flagged GDD's Status field in systems-index.md to "Needs Revision". @@ -575,7 +575,7 @@ Confirm in conversation: "Session state updated." ## Phase 7: Handoff -After all file writes are complete, use `AskUserQuestion` for a closing widget. +After all file writes are complete, use `question` for a closing widget. Before building options, check project state: - Are there any Warning-level items that are simple edits (flagged with "30-second edit", "brief addition", or similar)? → offer inline quick-fix option @@ -605,7 +605,7 @@ If any spawned agent returns BLOCKED, errors, or fails to complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" before continuing 2. **Assess dependencies**: If the blocked agent's output is required by a later phase, do not proceed past that phase without user input -3. **Offer options** via AskUserQuestion with three choices: +3. **Offer options** via question with three choices: - Skip this agent and note the gap in the final report - Retry with narrower scope (fewer GDDs, single-system focus) - Stop here and resolve the blocker first diff --git a/.opencode/skills/setup-engine/SKILL.md b/.opencode/skills/setup-engine/SKILL.md index 14cb12b..b82e80c 100644 --- a/.opencode/skills/setup-engine/SKILL.md +++ b/.opencode/skills/setup-engine/SKILL.md @@ -3,7 +3,7 @@ name: setup-engine description: "Configure the project's game engine and version. Pins the engine in CLAUDE.md, detects knowledge gaps, and populates engine reference docs via WebSearch when the version is beyond the LLM's training data." argument-hint: "[engine] | [engine version] | refresh | upgrade [old-version] [new-version] | no args for guided selection" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, WebSearch, WebFetch, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, WebSearch, WebFetch, Task, question --- When this skill is invoked: @@ -34,7 +34,7 @@ If no engine is specified, run an interactive engine selection process: ### If the user wants to pick without a concept, ask in this order: -**Question 1 — Prior experience** (ask this first, always, via `AskUserQuestion`): +**Question 1 — Prior experience** (ask this first, always, via `question`): - Prompt: "Have you worked in any of these engines before?" - Options: `Godot` / `Unity` / `Unreal Engine 5` / `Multiple — I'll explain` / `None of them` - If they pick a specific engine → recommend that engine. Prior experience outweighs all other factors. Confirm with them and skip the matrix. @@ -42,7 +42,7 @@ If no engine is specified, run an interactive engine selection process: **Questions 2-6 — Decision matrix inputs** (only if no prior engine experience): -**Question 2 — Target platform** (ask this second, always, via `AskUserQuestion` — platform eliminates or heavily weights engines before any other factor): +**Question 2 — Target platform** (ask this second, always, via `question` — platform eliminates or heavily weights engines before any other factor): - Prompt: "What platforms are you targeting for this game?" - Options: `PC (Steam / Epic)` / `Mobile (iOS / Android)` / `Console` / `Web / Browser` / `Multiple platforms` - Platform rules that feed directly into the recommendation: @@ -99,11 +99,11 @@ Do NOT use a simple scoring matrix that eliminates engines. Instead, reason thro 2. Give a primary recommendation with honest reasoning 3. Name the best alternative and when to choose it instead 4. Explicitly state: "This is a starting point, not a verdict — you can always migrate engines, and many developers switch between projects." -5. Use `AskUserQuestion` to confirm: "Does this recommendation feel right, or would you like to explore a different engine?" +5. Use `question` to confirm: "Does this recommendation feel right, or would you like to explore a different engine?" - Options: `[Primary engine] (Recommended)` / `[Alternative engine]` / `[Third engine]` / `Explore further` / `Type something` **If the user picks "Explore further":** -Use `AskUserQuestion` with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Always include at minimum: +Use `question` with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Always include at minimum: - The primary engine's specific limitations for this concept (e.g., "How far can Godot 3D actually go for [genre]?") - The alternative engine's specific tradeoffs for this concept - Language choice impact on this concept's technical challenges @@ -230,7 +230,7 @@ Example filled section: ``` ### Remaining Sections -- **Performance Budgets**: Use `AskUserQuestion`: +- **Performance Budgets**: Use `question`: - Prompt: "Should I set default performance budgets now, or leave them for later?" - Options: `[A] Set defaults now (60fps, 16.6ms frame budget, engine-appropriate draw call limit)` / `[B] Leave as [TO BE CONFIGURED] — I'll set these when I know my target hardware` - If [A]: populate with the suggested defaults. If [B]: leave as placeholder. diff --git a/.opencode/skills/smoke-check/SKILL.md b/.opencode/skills/smoke-check/SKILL.md index 9392015..6502450 100644 --- a/.opencode/skills/smoke-check/SKILL.md +++ b/.opencode/skills/smoke-check/SKILL.md @@ -3,7 +3,7 @@ name: smoke-check description: "Run the critical path smoke test gate before QA hand-off. Executes the automated test suite, verifies core functionality, and produces a PASS/FAIL report. Run after a sprint's stories are implemented and before manual QA begins. A failed smoke check means the build is not ready for QA." argument-hint: "[sprint | quick | --platform pc|console|mobile|all]" user-invocable: true -allowed-tools: Read, Glob, Grep, Bash, Write, AskUserQuestion +allowed-tools: Read, Glob, Grep, Bash, Write, question --- # Smoke Check @@ -177,7 +177,7 @@ Tailor batches 2 and 3 to the actual systems identified from the sprint or QA plan. Replace bracketed placeholders with real mechanic names from the current sprint's stories. -Use `AskUserQuestion` to batch-verify. Keep to at most 3 calls. +Use `question` to batch-verify. Keep to at most 3 calls. **Batch 1 — Core stability (always run):** ``` @@ -412,6 +412,6 @@ agent to begin manual verification." gaps for `/story-done` to follow up on. - **`quick` argument** skips Phase 3 (coverage scan) and Phase 4 Batch 3. Use it for rapid re-checks after fixing a specific failure. -- Use `AskUserQuestion` for all manual smoke check verification. +- Use `question` for all manual smoke check verification. - **Never write the report without asking** — Phase 6 requires explicit approval before any file is created. diff --git a/.opencode/skills/sprint-plan/SKILL.md b/.opencode/skills/sprint-plan/SKILL.md index 8d335f1..55979d8 100644 --- a/.opencode/skills/sprint-plan/SKILL.md +++ b/.opencode/skills/sprint-plan/SKILL.md @@ -3,7 +3,7 @@ name: sprint-plan description: "Generates a new sprint plan or updates an existing one based on the current milestone, completed work, and available capacity. Pulls context from production documents and design backlogs." argument-hint: "[new|update|status] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question context: | !ls production/sprints/ 2>/dev/null --- @@ -200,7 +200,7 @@ Use `Glob` to look for `production/qa/qa-plan-sprint-[N].md` or any file in `pro > > Run `/qa-plan sprint` now, before starting any implementation. It takes one session and produces the test case requirements each story needs." -Use `AskUserQuestion`: +Use `question`: - Prompt: "No QA plan found for this sprint. How do you want to proceed?" - Options: - `[A] Run /qa-plan sprint now — I'll do that before starting implementation (Recommended)` diff --git a/.opencode/skills/start/SKILL.md b/.opencode/skills/start/SKILL.md index 9094e79..729a46c 100644 --- a/.opencode/skills/start/SKILL.md +++ b/.opencode/skills/start/SKILL.md @@ -3,7 +3,7 @@ name: start description: "First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions." argument-hint: "[no arguments]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, question --- # Guided Onboarding @@ -32,7 +32,7 @@ Store these findings internally to validate the user's self-assessment and tailo ## Phase 2: Ask Where the User Is -This is the first thing the user sees. Use `AskUserQuestion` with these exact options so the user can click rather than type: +This is the first thing the user sees. Use `question` with these exact options so the user can click rather than type: - **Prompt**: "Welcome to Claude Code Game Studios! Before I suggest anything, I'd like to understand where you're starting from. Where are you at with your game idea right now?" - **Options**: @@ -107,8 +107,8 @@ The user needs creative exploration before anything else. #### If C: Clear concept -1. Ask them to describe their concept in one sentence — genre and core mechanic. Use plain text, not AskUserQuestion (it's an open response). -2. Acknowledge the concept, then use `AskUserQuestion` to offer two paths: +1. Ask them to describe their concept in one sentence — genre and core mechanic. Use plain text, not question (it's an open response). +2. Acknowledge the concept, then use `question` to offer two paths: - **Prompt**: "How would you like to proceed?" - **Options**: - `Formalize it first` — Run `/brainstorm [concept]` to structure it into a proper game concept document @@ -169,7 +169,7 @@ Check if `production/review-mode.txt` already exists. **If it exists**: Read it and show the current mode — "Review mode is set to `[current]`." — then proceed to Phase 4. Do not ask again. -**If it does not exist**: Use `AskUserQuestion`: +**If it does not exist**: Use `question`: - **Prompt**: "One setup choice: how much design review would you want as you work through the workflow?" - **Options**: @@ -190,7 +190,7 @@ Create the `production/` directory if it does not exist. ## Phase 4: Confirm Before Proceeding -After presenting the recommended path, use `AskUserQuestion` to ask the user which step they'd like to take first. Never auto-run the next skill. +After presenting the recommended path, use `question` to ask the user which step they'd like to take first. Never auto-run the next skill. - **Prompt**: "Would you like to start with [recommended first step]?" - **Options**: diff --git a/.opencode/skills/story-done/SKILL.md b/.opencode/skills/story-done/SKILL.md index 59d9e06..fc6c5f7 100644 --- a/.opencode/skills/story-done/SKILL.md +++ b/.opencode/skills/story-done/SKILL.md @@ -3,7 +3,7 @@ name: story-done description: "End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint." argument-hint: "[story-file-path] [--review full|lean|solo]" user-invocable: true -allowed-tools: Read, Glob, Grep, Bash, Write, Edit, AskUserQuestion, Task +allowed-tools: Read, Glob, Grep, Bash, Write, Edit, question, Task --- # Story Done @@ -35,7 +35,7 @@ read that file directly. 1. Check `production/session-state/active.md` for the currently active story. 2. If not found there, read the most recent file in `production/sprints/` and look for stories marked IN PROGRESS. -3. If multiple in-progress stories are found, use `AskUserQuestion`: +3. If multiple in-progress stories are found, use `question`: - "Which story are we completing?" - Options: list the in-progress story file names. 4. If no story can be found, ask the user to provide the path. @@ -85,13 +85,13 @@ three methods: that should be in localization files. - **Dependency check**: if a criterion says "depends on X", check that X exists. -### Manual verification with confirmation (use `AskUserQuestion`) +### Manual verification with confirmation (use `question`) - Criteria about subjective qualities ("feels responsive", "animations play correctly") - Criteria about gameplay behaviour ("player takes damage when...", "enemy responds to...") - Performance criteria ("completes within Xms") — ask if profiled or accept as assumed -Batch up to 4 manual verification questions into a single `AskUserQuestion` call: +Batch up to 4 manual verification questions into a single `question` call: ``` question: "Does [criterion]?" @@ -115,7 +115,7 @@ For each acceptance criterion in the story: - **Unit test**: check `tests/unit/` for a test file or function name that matches the criterion's subject (use `Glob` and `Grep`) - **Integration test**: check `tests/integration/` similarly - - **Manual confirmation**: if the criterion was verified via `AskUserQuestion` + - **Manual confirmation**: if the criterion was verified via `question` above with a "Yes — passes" answer, count that as a manual test 2. Produce a traceability table: @@ -262,7 +262,7 @@ Spawn `lead-programmer` via Task using gate **LP-CODE-REVIEW** (`.opencode/docs/ Pass: implementation file paths, story file path, relevant GDD section, governing ADR. -Present the verdict to the user. If CONCERNS, surface them via `AskUserQuestion`: +Present the verdict to the user. If CONCERNS, surface them via `question`: - Options: `Revise flagged issues` / `Accept and proceed` / `Discuss further` If REJECT, do not proceed to Phase 6 verdict until the issues are resolved. @@ -416,7 +416,7 @@ If no more stories are ready but Must Have stories are still In Progress (not Co decides if they are acceptable. - **BLOCKED verdict is advisory** — the user can override and mark complete anyway; document the risk explicitly if they do. -- Use `AskUserQuestion` for the code review prompt and for batching manual +- Use `question` for the code review prompt and for batching manual criteria confirmations. --- diff --git a/.opencode/skills/story-readiness/SKILL.md b/.opencode/skills/story-readiness/SKILL.md index 92279cc..c868749 100644 --- a/.opencode/skills/story-readiness/SKILL.md +++ b/.opencode/skills/story-readiness/SKILL.md @@ -3,7 +3,7 @@ name: story-readiness description: "Validate that a story file is implementation-ready. Checks for embedded GDD requirements, ADR references, engine notes, clear acceptance criteria, and no open design questions. Produces READY / NEEDS WORK / BLOCKED verdict with specific gaps. Use when user says 'is this story ready', 'can I start on this story', 'is story X ready to implement'." argument-hint: "[story-file-path or 'all' or 'sprint']" user-invocable: true -allowed-tools: Read, Glob, Grep, AskUserQuestion, Task +allowed-tools: Read, Glob, Grep, question, Task model: haiku --- @@ -35,7 +35,7 @@ See `.opencode/docs/director-gates.md` for the full check pattern and mode defin ## 1. Parse Arguments -**Scope:** `$ARGUMENTS[0]` (blank = ask user via AskUserQuestion) +**Scope:** `$ARGUMENTS[0]` (blank = ask user via question) - **Specific path** (e.g., `/story-readiness production/epics/combat/story-001-basic-attack.md`): validate that single story file. @@ -45,7 +45,7 @@ See `.opencode/docs/director-gates.md` for the full check pattern and mode defin validate every story file found. - **No argument**: ask the user which scope to validate. -If no argument is given, use `AskUserQuestion`: +If no argument is given, use `question`: - "What would you like to validate?" - Options: "A specific story file", "All stories in the current sprint", "All stories in production/epics/", "Stories for a specific epic" @@ -335,7 +335,7 @@ Pass the following context: Handle the verdict per standard rules in `director-gates.md`: - **ADEQUATE** → story is cleared. Proceed to close. -- **GAPS [list]** → surface the specific gaps to the user via `AskUserQuestion`: +- **GAPS [list]** → surface the specific gaps to the user via `question`: options: `Update story with suggested gaps` / `Accept and proceed anyway` / `Discuss further`. - **INADEQUATE** → surface the specific gaps; ask user whether to update the story or proceed anyway. diff --git a/.opencode/skills/team-audio/SKILL.md b/.opencode/skills/team-audio/SKILL.md index 553f4c8..bd240cd 100644 --- a/.opencode/skills/team-audio/SKILL.md +++ b/.opencode/skills/team-audio/SKILL.md @@ -3,15 +3,15 @@ name: team-audio description: "Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation." argument-hint: "[feature or area to design audio for]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- If no argument is provided, output usage guidance and exit without spawning any agents: -> Usage: `/team-audio [feature or area]` — specify the feature or area to design audio for (e.g., `combat`, `main menu`, `forest biome`, `boss encounter`). Do not use `AskUserQuestion` here; output the guidance directly. +> Usage: `/team-audio [feature or area]` — specify the feature or area to design audio for (e.g., `combat`, `main menu`, `forest biome`, `boss encounter`). Do not use `question` here; output the guidance directly. When this skill is invoked with an argument, orchestrate the audio team through a structured pipeline. -**Decision Points:** At each step transition, use `AskUserQuestion` to present +**Decision Points:** At each step transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next step. @@ -116,7 +116,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-combat/SKILL.md b/.opencode/skills/team-combat/SKILL.md index 1781108..784058c 100644 --- a/.opencode/skills/team-combat/SKILL.md +++ b/.opencode/skills/team-combat/SKILL.md @@ -3,7 +3,7 @@ name: team-combat description: "Orchestrate the combat team: coordinates game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, and qa-tester to design, implement, and validate a combat feature end-to-end." argument-hint: "[combat feature description]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- **Argument check:** If no combat feature description is provided, output: > "Usage: `/team-combat [combat feature description]` — Provide a description of the combat feature to design and implement (e.g., `melee parry system`, `ranged weapon spread`)." @@ -11,7 +11,7 @@ Then stop immediately without spawning any subagents or reading any files. When this skill is invoked with a valid argument, orchestrate the combat team through a structured pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -88,7 +88,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-level/SKILL.md b/.opencode/skills/team-level/SKILL.md index b5dc161..30eed0f 100644 --- a/.opencode/skills/team-level/SKILL.md +++ b/.opencode/skills/team-level/SKILL.md @@ -3,12 +3,12 @@ name: team-level description: "Orchestrate level design team: level-designer + narrative-director + world-builder + art-director + systems-designer + qa-tester for complete area/level creation." argument-hint: "[level name or area to design]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- When this skill is invoked: -**Decision Points:** At each step transition, use `AskUserQuestion` to present +**Decision Points:** At each step transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next step. @@ -61,7 +61,7 @@ Spawn the `art-director` agent to: **The art-director's visual targets from Step 1 must be passed to the level-designer in Step 2** as explicit constraints. Layout decisions happen within the visual direction, not before it. -**Gate**: Use `AskUserQuestion` to present all three Step 1 outputs (narrative brief, lore foundation, visual direction targets) and confirm before proceeding to Step 2. +**Gate**: Use `question` to present all three Step 1 outputs (narrative brief, lore foundation, visual direction targets) and confirm before proceeding to Step 2. ### Step 2: Layout and Encounter Design (level-designer) Spawn the `level-designer` agent with the full Step 1 output as context: @@ -80,13 +80,13 @@ The level-designer should: **Adjacent area dependency check**: After the layout is produced, check `design/levels/` for each adjacent area referenced by the level-designer. If any referenced area's `.md` file does not exist, surface the gap: > "Level references [area-name] as an adjacent area but `design/levels/[area-name].md` does not exist." -Use `AskUserQuestion` with options: +Use `question` with options: - (a) Proceed with a placeholder reference — mark the connection as UNRESOLVED in the level doc and list it in the open cross-level dependencies section of the summary report - (b) Pause and run `/team-level [area-name]` first to establish that area Do NOT invent content for the missing adjacent area. -**Gate**: Use `AskUserQuestion` to present Step 2 layout (including any unresolved adjacent area dependencies) and confirm before proceeding to Step 3. +**Gate**: Use `question` to present Step 2 layout (including any unresolved adjacent area dependencies) and confirm before proceeding to Step 3. ### Step 3: Systems Integration (systems-designer) Spawn the `systems-designer` agent to: @@ -96,7 +96,7 @@ Spawn the `systems-designer` agent to: - Design any area-specific mechanics or environmental hazards - Specify resource distribution (health pickups, save points, shops) -**Gate**: Use `AskUserQuestion` to present Step 3 outputs and confirm before proceeding to Step 4. +**Gate**: Use `question` to present Step 3 outputs and confirm before proceeding to Step 4. ### Step 4: Production Concepts + Accessibility (art-director + accessibility-specialist, parallel) @@ -118,7 +118,7 @@ Spawn the `accessibility-specialist` agent in parallel to: Wait for both agents to return before proceeding. -**Gate**: Use `AskUserQuestion` to present both Step 4 results. If the accessibility-specialist returned any BLOCKING concerns, highlight them prominently and offer: +**Gate**: Use `question` to present both Step 4 results. If the accessibility-specialist returned any BLOCKING concerns, highlight them prominently and offer: - (a) Return to level-designer and art-director to redesign the flagged elements before Step 5 - (b) Document as a known accessibility gap and proceed to Step 5 with the concern explicitly logged in the final report @@ -162,7 +162,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-live-ops/SKILL.md b/.opencode/skills/team-live-ops/SKILL.md index c4f6e7f..1d85404 100644 --- a/.opencode/skills/team-live-ops/SKILL.md +++ b/.opencode/skills/team-live-ops/SKILL.md @@ -3,7 +3,7 @@ name: team-live-ops description: "Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update." argument-hint: "[season name or event description]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- **Argument check:** If no season name or event description is provided, output: > "Usage: `/team-live-ops [season name or event description]` — Provide the name or description of the season or live event to plan." @@ -11,7 +11,7 @@ Then stop immediately without spawning any subagents or reading any files. When this skill is invoked with a valid argument, orchestrate the live-ops team through a structured planning pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -100,7 +100,7 @@ Present a summary to the user with: - **Analytics readiness**: are success criteria defined and instrumented? - **Ethics review**: check the Phase 3 economy design against `design/live-ops/ethics-policy.md` - If the file does not exist: flag "ETHICS REVIEW SKIPPED: `design/live-ops/ethics-policy.md` not found. Economy design was not reviewed against an ethics policy. Recommend creating one before production begins." Include this flag in the season design output document. Add to next steps: create `design/live-ops/ethics-policy.md`. - - If the file exists and a violation is found: flag "ETHICS FLAG: [element] in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved." Do NOT issue a COMPLETE verdict or write output documents. Use `AskUserQuestion` with options: revise economy design / override with documented rationale / cancel. If user chooses to revise: re-spawn economy-designer to produce a corrected design, then return to Phase 7 review. + - If the file exists and a violation is found: flag "ETHICS FLAG: [element] in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved." Do NOT issue a COMPLETE verdict or write output documents. Use `question` with options: revise economy design / override with documented rationale / cancel. If user chooses to revise: re-spawn economy-designer to produce a corrected design, then return to Phase 7 review. - **Open questions**: decisions still needed before production begins Ask the user to approve the season plan before delegating to production teams. Issue the COMPLETE verdict only after the user approves and no unresolved ethics violations remain. If an ethics violation is unresolved, end with Verdict: **BLOCKED**. @@ -118,7 +118,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-narrative/SKILL.md b/.opencode/skills/team-narrative/SKILL.md index 373ad22..48f8c27 100644 --- a/.opencode/skills/team-narrative/SKILL.md +++ b/.opencode/skills/team-narrative/SKILL.md @@ -3,14 +3,14 @@ name: team-narrative description: "Orchestrate the narrative team: coordinates narrative-director, writer, world-builder, and level-designer to create cohesive story content, world lore, and narrative-driven level design." argument-hint: "[narrative content description]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Task, question, TodoWrite --- If no argument is provided, output usage guidance and exit without spawning any agents: -> Usage: `/team-narrative [narrative content description]` — describe the story content, scene, or narrative area to work on (e.g., `boss encounter cutscene`, `faction intro dialogue`, `tutorial narrative`). Do not use `AskUserQuestion` here; output the guidance directly. +> Usage: `/team-narrative [narrative content description]` — describe the story content, scene, or narrative area to work on (e.g., `boss encounter cutscene`, `faction intro dialogue`, `tutorial narrative`). Do not use `question` here; output the guidance directly. When this skill is invoked with an argument, orchestrate the narrative team through a structured pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -76,7 +76,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-polish/SKILL.md b/.opencode/skills/team-polish/SKILL.md index 5cdd6ca..858768d 100644 --- a/.opencode/skills/team-polish/SKILL.md +++ b/.opencode/skills/team-polish/SKILL.md @@ -3,14 +3,14 @@ name: team-polish description: "Orchestrate the polish team: coordinates performance-analyst, technical-artist, sound-designer, and qa-tester to optimize, polish, and harden a feature or area for release quality." argument-hint: "[feature or area to polish]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- If no argument is provided, output usage guidance and exit without spawning any agents: -> Usage: `/team-polish [feature or area]` — specify the feature or area to polish (e.g., `combat`, `main menu`, `inventory system`, `level-1`). Do not use `AskUserQuestion` here; output the guidance directly. +> Usage: `/team-polish [feature or area]` — specify the feature or area to polish (e.g., `combat`, `main menu`, `inventory system`, `level-1`). Do not use `question` here; output the guidance directly. When this skill is invoked with an argument, orchestrate the polish team through a structured pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -95,7 +95,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-qa/SKILL.md b/.opencode/skills/team-qa/SKILL.md index f8ba570..6d4e7ec 100644 --- a/.opencode/skills/team-qa/SKILL.md +++ b/.opencode/skills/team-qa/SKILL.md @@ -3,13 +3,13 @@ name: team-qa description: "Orchestrate the QA team through a full testing cycle. Coordinates qa-lead (strategy + test plan) and qa-tester (test case writing + bug reporting) to produce a complete QA package for a sprint or feature. Covers: test plan generation, test case writing, smoke check gate, manual QA execution, and sign-off report." argument-hint: "[sprint | feature: system-name]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion +allowed-tools: Read, Glob, Grep, Write, Task, question agent: qa-lead --- When this skill is invoked, orchestrate the QA team through a structured testing cycle. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -63,7 +63,7 @@ Prompt the qa-lead to: If the smoke check result is **FAIL**, the qa-lead must list the failures prominently. QA cannot proceed past the strategy phase with a failed smoke check. -Present the qa-lead's full strategy to the user, then use `AskUserQuestion`: +Present the qa-lead's full strategy to the user, then use `question`: ``` question: "QA Strategy Review" @@ -117,7 +117,7 @@ Each test case set should include: Present the test cases to the user for review before execution. Group by story. -Use `AskUserQuestion` per story group (batched 3-4 at a time): +Use `question` per story group (batched 3-4 at a time): ``` question: "Test cases ready for [Story Group]. Review before manual QA begins?" @@ -131,7 +131,7 @@ options: Walk through each story in the approved manual QA list. -Batch stories into groups of 3-4 and use `AskUserQuestion` for each: +Batch stories into groups of 3-4 and use `question` for each: ``` question: "Manual QA — [Story Title]\n[brief description of what to test]" @@ -142,7 +142,7 @@ options: - "BLOCKED — cannot test yet (reason)" ``` -After each FAIL result: use `AskUserQuestion` to collect the failure description, then spawn `qa-tester` via Task to write a formal bug report in `production/qa/bugs/`. +After each FAIL result: use `question` to collect the failure description, then spawn `qa-tester` via Task to write a formal bug report in `production/qa/bugs/`. Bug report naming: `BUG-[NNN]-[short-slug].md` (increment NNN from existing bugs in the directory). @@ -202,7 +202,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-release/SKILL.md b/.opencode/skills/team-release/SKILL.md index 845199f..09fcb9f 100644 --- a/.opencode/skills/team-release/SKILL.md +++ b/.opencode/skills/team-release/SKILL.md @@ -3,16 +3,16 @@ name: team-release description: "Orchestrate the release team: coordinates release-manager, qa-lead, devops-engineer, and producer to execute a release from candidate to deployment." argument-hint: "[version number or 'next']" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- **Argument check:** If no version number is provided: 1. Read `production/session-state/active.md` and the most recent file in `production/milestones/` (if they exist) to infer the target version. -2. If a version is found: report "No version argument provided — inferred [version] from milestone data. Proceeding." Then confirm with `AskUserQuestion`: "Releasing [version]. Is this correct?" -3. If no version is discoverable: use `AskUserQuestion` to ask "What version number should be released? (e.g., v1.0.0)" and wait for user input before proceeding. Do NOT default to a hardcoded version string. +2. If a version is found: report "No version argument provided — inferred [version] from milestone data. Proceeding." Then confirm with `question`: "Releasing [version]. Is this correct?" +3. If no version is discoverable: use `question` to ask "What version number should be released? (e.g., v1.0.0)" and wait for user input before proceeding. Do NOT default to a hardcoded version string. When this skill is invoked, orchestrate the release team through a structured pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -80,7 +80,7 @@ Delegate to **producer**: **If producer declares NO-GO:** - Surface the decision immediately: "PRODUCER: NO-GO — [rationale, e.g., S1 bug found in Phase 3]." -- Use `AskUserQuestion` with options: +- Use `question` with options: - Fix the blocker and re-run the affected phase - Defer the release to a later date - Override NO-GO with documented rationale (user must provide written justification) @@ -116,7 +116,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/team-ui/SKILL.md b/.opencode/skills/team-ui/SKILL.md index ba791b2..9d12359 100644 --- a/.opencode/skills/team-ui/SKILL.md +++ b/.opencode/skills/team-ui/SKILL.md @@ -3,11 +3,11 @@ name: team-ui description: "Orchestrate the UI team through the full UX pipeline: from UX spec authoring through visual design, implementation, review, and polish. Integrates with /ux-design, /ux-review, and studio UX templates." argument-hint: "[UI feature description]" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite +allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, question, TodoWrite --- When this skill is invoked, orchestrate the UI team through a structured pipeline. -**Decision Points:** At each phase transition, use `AskUserQuestion` to present +**Decision Points:** At each phase transition, use `question` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. @@ -50,7 +50,7 @@ Before designing anything, read and synthesize: **If `design/ux/interaction-patterns.md` does not exist**, surface the gap immediately: > "interaction-patterns.md does not exist — no existing patterns to reuse." -Then use `AskUserQuestion` with options: +Then use `question` with options: - (a) Run `/ux-design patterns` first to establish the pattern library, then continue - (b) Proceed without the pattern library — ui-programmer will treat all patterns created as new and add each to a new `design/ux/interaction-patterns.md` at completion @@ -74,7 +74,7 @@ Output: `design/ux/[feature-name].md` with all required spec sections filled. After the spec is complete, invoke `/ux-review design/ux/[feature-name].md`. -**Gate**: Do not proceed to Phase 2 until the verdict is APPROVED. If the verdict is NEEDS REVISION, the ux-designer must address the flagged issues and re-run the review. The user may explicitly accept a NEEDS REVISION risk and proceed, but this must be a conscious decision — present the specific concerns via `AskUserQuestion` before asking whether to proceed. +**Gate**: Do not proceed to Phase 2 until the verdict is APPROVED. If the verdict is NEEDS REVISION, the ux-designer must address the flagged issues and re-run the review. The user may explicitly accept a NEEDS REVISION risk and proceed, but this must be a conscious decision — present the specific concerns via `question` before asking whether to proceed. ### Phase 2: Visual Design @@ -138,7 +138,7 @@ If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete: 1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases 2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input. -3. **Offer options** via AskUserQuestion with choices: +3. **Offer options** via question with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first diff --git a/.opencode/skills/ux-design/SKILL.md b/.opencode/skills/ux-design/SKILL.md index a747595..3e76cc2 100644 --- a/.opencode/skills/ux-design/SKILL.md +++ b/.opencode/skills/ux-design/SKILL.md @@ -3,7 +3,7 @@ name: ux-design description: "Guided, section-by-section UX spec authoring for a screen, flow, or HUD. Reads game concept, player journey, and relevant GDDs to provide context-aware design guidance. Produces ux-spec.md (per screen/flow) or hud-design.md using the studio templates." argument-hint: "[screen/flow name] or 'hud' or 'patterns'" user-invocable: true -allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Task +allowed-tools: Read, Glob, Grep, Write, Edit, question, Task agent: ux-designer --- @@ -20,7 +20,7 @@ Three authoring modes exist based on the argument: | Any other value (e.g., `main-menu`, `inventory`) | UX spec for a screen or flow | `design/ux/[argument].md` | | No argument | Ask the user | (see below) | -**If no argument is provided**, do not fail — ask instead. Use `AskUserQuestion`: +**If no argument is provided**, do not fail — ask instead. Use `question`: - "What are we designing today?" - Options: "A specific screen or flow (I'll name it)", "The game HUD", "The interaction pattern library", "I'm not sure — help me figure it out" @@ -409,10 +409,10 @@ Context -> Questions -> Options -> Decision -> Draft -> Approval -> 1. **Context**: State what this section needs to contain and surface any relevant constraints from context gathered in Phase 2. -2. **Questions**: Ask what is needed to draft this section. Use `AskUserQuestion` +2. **Questions**: Ask what is needed to draft this section. Use `question` for constrained choices, conversational text for open-ended exploration. 3. **Options**: Where design choices exist, present 2-4 approaches with pros/cons. - Explain reasoning in conversation, then use `AskUserQuestion` to capture the decision. + Explain reasoning in conversation, then use `question` to capture the decision. 4. **Decision**: User picks an approach or provides custom direction. 5. **Draft**: Write the section content in conversation for review. Flag provisional assumptions explicitly. @@ -513,7 +513,7 @@ This is the largest and most interactive section. Work through it in sub-section **Sub-section 4 — ASCII Wireframe**: - Offer to generate an ASCII wireframe based on the zone layout and component list. -- Use `AskUserQuestion`: "Want an ASCII wireframe as part of this spec?" +- Use `question`: "Want an ASCII wireframe as part of this spec?" - Options: "Yes, include one", "No, I'll attach a separate file" - If yes, produce the wireframe in conversation first. Ask for feedback before writing it to file. @@ -631,7 +631,7 @@ Walk through the ux-designer agent's standard checklist for this screen: - Screen reader considerations for any non-text elements - Any motion or animation that needs a reduced-motion alternative -Use `AskUserQuestion` to surface any open questions on accessibility tier: +Use `question` to surface any open questions on accessibility tier: - "Has the accessibility tier been committed to for this project?" - Options: "Yes, read from requirements doc", "Not yet — let's flag it as a question", "Skip accessibility section for now" @@ -716,7 +716,7 @@ For each item, ask the user to categorize it: | **On Demand** | Player must actively request it (toggle, hold button) | | **Hidden** | Communicated through world/audio, never on-screen text | -Use `AskUserQuestion` to step through items in groups of 3-4, not all at once. +Use `question` to step through items in groups of 3-4, not all at once. This is the most consequential design decision in the HUD — do not rush it. **Conflict check**: If the information philosophy (Section A) says "nearly HUD-free" @@ -882,7 +882,7 @@ Before presenting options, state clearly: > implementation pipeline. The Pre-Production gate requires all key screen specs > to have a review verdict." -Then use `AskUserQuestion`: +Then use `question`: - "Run `/ux-review [filename]` now, or do something else first?" - Options: - "Run `/ux-review` now — validate this spec" @@ -942,7 +942,7 @@ When delegating to another agent via the Task tool: This skill follows the collaborative design principle at every step: 1. **Question -> Options -> Decision -> Draft -> Approval** for every section -2. **AskUserQuestion** at every decision point (Explain -> Capture pattern): +2. **question** at every decision point (Explain -> Capture pattern): - Phase 2: "Ready to start, or need more context?" - Phase 3: "May I create the skeleton?" - Phase 4 (each section): design questions, approach options, draft approval