team-ui

When this skill is invoked, orchestrate the UI team through a structured pipeline. **Decision Points:** At each phase transition, present a concise plain-text choice list to 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. ## 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 `docs/studio/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 subagent workflow to spawn each team member as a subagent: - `custom agent: ux-designer` — User flows, wireframes, accessibility, input handling - `custom agent: ui-programmer` — UI framework, screens, widgets, data binding - `custom agent: art-director` — Visual style, layout polish, art bible consistency - `custom agent: [UI engine specialist]` — Engine-specific UI pattern validation (e.g., unity-ui-specialist, ue-umg-specialist, godot-specialist) - `custom agent: 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 ask the user directly in plain text 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 a concise plain-text choice list 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 bible: colors, typography, spacing, animation style - Check that visual design preserves accessibility compliance: verify color contrast ratios, and confirm color is never the only indicator of state (shape, text, or icon must reinforce it) - Specify all asset requirements needed from the art pipeline: icons at specified sizes, background textures, fonts, decorative elements — with precise dimensions and format requirements - Ensure consistency with existing implemented UI screens - Output: visual design spec with style notes and asset manifest ### Phase 3: Implementation Before implementation begins, spawn the **engine UI specialist** (from `docs/studio/technical-preferences.md` Engine Specialists → UI Specialist) to review the UX spec and visual design spec for engine-specific implementation guidance: - Which engine UI framework should be used for this screen? (e.g., UI Toolkit vs UGUI in Unity, Control nodes vs CanvasLayer in Godot, UMG vs CommonUI in Unreal) - Any engine-specific gotchas for the proposed layout or interaction patterns? - Recommended widget/node structure for the engine? - Output: engine UI implementation notes to hand off to ui-programmer before they begin If no engine is configured, skip this step. Delegate to **ui-programmer**: - Implement the UI following the UX spec and visual design spec - **Use patterns from `design/ux/interaction-patterns.md`** — do not reinvent patterns that are already specified. If a pattern almost fits but needs modification, note the deviation and flag it for ux-designer review. - **UI NEVER owns or modifies game state** — display only; emit events for all player actions - All text through the localization system — no hardcoded player-facing strings - Support both input methods (keyboard/mouse AND gamepad) - Implement accessibility features per the committed tier in `design/accessibility-requirements.md` - Wire up data binding to game state - **If any new interaction pattern is created during implementation** (i.e., something not already in the pattern library), add it to `design/ux/interaction-patterns.md` before marking implementation complete - Output: implemented UI feature ### Phase 4: Review (parallel) Delegate in parallel: - **ux-designer**: Verify implementation matches wireframes and interaction spec. Test keyboard-only and gamepad-only navigation. Check accessibility features function correctly. - **art-director**: Verify visual consistency with art bible. Check at minimum and maximum supported resolutions. - **accessibility-specialist**: Verify compliance against the committed accessibility tier documented in `design/accessibility-requirements.md`. Flag any violations as blockers. All three review streams must report before proceeding to Phase 5. ### Phase 5: Polish - Address all review feedback - Verify animations are skippable and respect the player's motion reduction preferences - Confirm UI sounds trigger through the audio event system (no direct audio calls) - Test at all supported resolutions and aspect ratios - **Verify `design/ux/interaction-patterns.md` is up to date** — if any new patterns were introduced during this feature's implementation, confirm they have been added to the library - **Confirm all HUD elements respect the visual budget** defined in `design/ux/hud.md` (element count, screen region allocations, maximum opacity values) ## Quick Reference — When to Use Which Skill - `$ux-design` — Author a new UX spec for a screen, flow, or HUD from scratch - `$ux-review` — Validate a completed UX spec before implementation - `$team-ui [feature]` — Full pipeline from concept through polish (calls `$ux-design` and `$ux-review` internally) - `$quick-design` — Small UI changes that don't need a full new UX spec ## Error Recovery Protocol If any spawned agent (as a subagent) 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 a concise plain-text choice list with choices: - Skip this agent and note the gap in the final report - Retry with narrower scope - Stop here and resolve the blocker first 4. **Always produce a partial report** — output whatever was completed. Never discard work because one agent blocked. Common blockers: - Input file missing (story not found, GDD absent) → redirect to the skill that creates it - ADR status is Proposed → do not implement; run `$architecture-decision` first - Scope too large → split into two stories via `$create-stories` - Conflicting instructions between ADR and story → surface the conflict, do not guess ## File Write Protocol All file writes (UX specs, interaction pattern library updates, implementation files) are delegated to sub-agents and sub-skills (`$ux-design`, `ui-programmer`). Each enforces the "May I write to [path]?" protocol. This orchestrator does not write files directly. ## Output A summary report covering: UX spec status, UX review verdict, visual design status, implementation status, accessibility compliance, input method support, interaction pattern library update status, and any outstanding issues. Verdict: **COMPLETE** — UI feature delivered through full pipeline (UX spec → visual → implementation → review → polish). Verdict: **BLOCKED** — pipeline halted; surface the blocker and its phase before stopping. ## Next Steps - Run `$ux-review` on the final spec if not yet approved. - Run `$code-review` on the UI implementation before closing stories. - Run `$team-polish` if visual or audio polish pass is needed.