/team-ui

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] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
model: sonnet

When this skill is invoked, orchestrate the UI team through a structured pipeline.

**Decision Points:** At each phase transition, use `AskUserQuestion` 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.

Phase 0: Resolve Review Mode

1. If `--review [mode]` was passed as an argument, use that mode. 2. Else read `production/review-mode.txt` — use whatever is written there. 3. Else default to `lean`.

Modes:

• `full` — spawn all director and lead gates as described
• `lean` — skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
• `solo` — skip all director gate spawning entirely; run the skill without any agent gates

Store the resolved mode for use in all subsequent phases.

**Director gate skip rule**: Before spawning creative-director, art-director, or any other Tier 1/2 director for review (outside of PHASE-GATE triggers), apply the resolved mode: skip if solo mode; skip if lean mode and this is not a PHASE-GATE.

Team Composition

• **ux-designer** — User flows, wireframes, accessibility, input handling
• **ui-programmer** — UI framework, screens, widgets, data binding, implementation
• **art-director** — Visual style, layout polish, consistency with art bible
• **engine UI specialist** — Validates UI implementation patterns against engine-specific best practices (read from `.claude/docs/technical-preferences.md` Engine Specialists → UI Specialist)
• **accessibility-specialist** — Audits accessibility compliance at Phase 4

**Templates used by this pipeline:**

• `ux-spec.md` — Standard screen/flow UX specification
• `hud-design.md` — HUD-specific UX specification
• `interaction-pattern-library.md` — Reusable interaction patterns
• `accessibility-requirements.md` — Committed accessibility tier and requirements

How to Delegate

Use the Task tool to spawn each team member as a subagent:

• `subagent_type: ux-designer` — User flows, wireframes, accessibility, input handling
• `subagent_type: ui-programmer` — UI framework, screens, widgets, data binding
• `subagent_type: art-director` — Visual style, layout polish, art bible consistency
• `subagent_type: [UI engine specialist]` — Engine-specific UI pattern validation (e.g., unity-ui-specialist, ue-umg-specialist, godot-specialist)
• `subagent_type: accessibility-specialist` — Accessibility compliance audit

Always provide full context in each agent's prompt (feature requirements, existing UI patterns, platform targets). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 4 review agents can run simultaneously).

Pipeline

Phase 1a: Context Gathering

Before designing anything, read and synthesize:

• `design/gdd/game-concept.md` — platform targets and intended audience
• `design/player-journey.md` — player's state and context when they reach this screen
• All GDD UI Requirements sections relevant to this feature
• `design/ux/interaction-patterns.md` — existing patterns to reuse (not reinvent)
• `design/accessibility-requirements.md` — committed accessibility tier (e.g., Basic, Enhanced, Full)

**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:

• (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

Do NOT invent or assume patterns from the feature name or GDD alone. If the user chooses (b), explicitly instruct ui-programmer in Phase 3 to treat all patterns as new and document them in `design/ux/interaction-patterns.md` when implementation is complete. Note the pattern library status (created / absent / updated) in the final summary report.

Summarize the context in a brief for the ux-designer: what the player is doing, what they need, what constraints apply, and which existing patterns are relevant.

Phase 1b: UX Spec Authoring

Invoke `/ux-design [feature name]` skill OR delegate directly to ux-designer to produce `design/ux/[feature-name].md` following the `ux-spec.md` template.

If designing the HUD, use the `hud-design.md` template instead of `ux-spec.md`.

> **Notes on special cases:** > - For HUD design specifically, invoke `/ux-design` with `argument: hud` (e.g., `/ux-design hud`). > - For the interaction pattern library, run `/ux-design patterns` once at project start and update it whenever new patterns are introduced during later phases.

Output: `design/ux/[feature-name].md` with all required spec sections filled.

Phase 1c: UX Review

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.

Phase 2: Visual Design

Delegate to **art-director**:

• Review the full UX spec (flows, wireframes, interaction patterns, accessibility notes) — not just the wireframe images
• Apply visual treatment from the art bi