# Team Ui > Orquesta al equipo de UI a través de todo el pipeline UX: desde la especificación UX hasta diseño visual, implementación, revisión y pulido, integrándose con /ux-design y /ux-review. Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-ui Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-ui.md Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios Autor: Donchitos Licencia: MIT Actualizado: hace 3 meses Coste de contexto: 50 tok instalada, 3k tok al activarse, 3k tok con todos los archivos del bundle Bundle: 1 archivo, 12 KB Permisos que pide: read, glob, grep, write, edit, bash, task, askuserquestion, todowrite ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent claude-code # Cursor npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent cursor # Codex npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent codex # Gemini CLI npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent gemini # Windsurf npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent windsurf # Cline npx -y skills add Donchitos/Claude-Code-Game-Studios --skill team-ui --agent cline ``` ## Qué hace - Orquesta un pipeline UI completo: contexto, especificación UX, diseño visual, implementación, revisión y pulido - Delega tareas a subagentes (ux-designer, ui-programmer, art-director, especialista de motor UI, accessibility-specialist) - Usa AskUserQuestion en cada transición de fase para que el usuario apruebe antes de avanzar - Resuelve el modo de revisión (full/lean/solo) y ajusta qué gates de directores se ejecutan - Genera un informe final con el estado de cada fase y el veredicto COMPLETE o BLOCKED ## Cuándo usarla - Se necesita construir una feature de UI completa, desde la especificación UX hasta la implementación y el pulido - Se requiere coordinar a todo el equipo de UI (diseño, arte, implementación, revisión de accesibilidad) en un solo flujo ## Cuándo no - Cambios de UI pequeños que no necesitan una nueva especificación UX completa (usar /quick-design en su lugar) ## Qué la activa - "/team-ui pantalla de inventario --review full" - "Orquesta el pipeline de UI completo para el HUD del juego" - "Necesito diseñar, implementar y revisar una nueva pantalla de menú" ## Antes de instalar - Requiere plantillas y documentos del estudio como design/gdd/game-concept.md, design/accessibility-requirements.md y .claude/docs/technical-preferences.md. - runs shell commands - writes to your files ## Archivos - SKILL.md — 12 KB ## SKILL.md Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés. 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 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 `.claude/docs/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 (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: - 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. ## Dónde encaja - Categoría: [Diseño y UI](https://skillsagentes.com/categorias/diseno-ui.md) — Sistemas de diseño, trabajo con componentes y acabado visual. - Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off. - [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first. - [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento. - [Day One Patch](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md): Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback. - [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)