team-ui

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

调用此Skill时，将通过结构化流程统筹UI团队开展工作。

决策节点： 在每个阶段过渡时，使用

AskUserQuestion

将子Agent的提案以可选选项形式呈现给用户。在对话中撰写Agent的完整分析，然后用简洁标签记录决策结果。必须获得用户批准后，才能进入下一阶段。

Phase 0: Resolve Review Mode

阶段0：确定评审模式

If
```
--review [mode]
```
was passed as an argument, use that mode.
Else read
```
production/review-mode.txt
```
— use whatever is written there.
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.

如果传入了
```
--review [mode]
```
参数，则使用该模式。
否则读取
```
production/review-mode.txt
```
文件，使用其中记录的模式。
若以上均无，则默认使用
```
lean
```
模式。

模式说明：

```
full
```
—— 按描述启用所有主管和负责人关卡
```
lean
```
—— 跳过主管关卡，除非是PHASE-GATE类型（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）
```
solo
```
—— 完全跳过所有主管关卡；无需任何Agent关卡即可运行该Skill

保存确定后的模式，供后续所有阶段使用。

主管关卡跳过规则：在启用创意主管（creative-director）、艺术主管（art-director）或其他1/2级主管进行评审时（PHASE-GATE触发的情况除外），应用已确定的模式：若为solo模式则跳过；若为lean模式且当前不是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

ux-designer —— 用户流程、线框图、无障碍设计、输入交互处理
ui-programmer —— UI框架、界面、组件、数据绑定、开发实现
art-director —— 视觉风格、布局打磨、与美术规范一致性
engine UI specialist —— 根据引擎特定最佳实践验证UI实现模式（读取
```
.claude/docs/technical-preferences.md
```
中Engine Specialists → UI Specialist部分内容）
accessibility-specialist —— 在阶段4审核无障碍合规性

本流程使用的模板：

```
ux-spec.md
```
—— 标准界面/流程UX规范
```
hud-design.md
```
—— HUD专属UX规范
```
interaction-pattern-library.md
```
—— 可复用交互模式库
```
accessibility-requirements.md
```
—— 已确定的无障碍等级及要求

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).

使用Task工具将每个团队成员作为子Agent启用：

```
subagent_type: ux-designer
```
—— 用户流程、线框图、无障碍设计、输入交互处理
```
subagent_type: ui-programmer
```
—— UI框架、界面、组件、数据绑定
```
subagent_type: art-director
```
—— 视觉风格、布局打磨、美术规范一致性
```
subagent_type: [UI engine specialist]
```
—— 引擎特定UI模式验证（例如：unity-ui-specialist、ue-umg-specialist、godot-specialist）
```
subagent_type: accessibility-specialist
```
—— 无障碍合规性审核

在每个Agent的提示语中提供完整上下文（功能需求、现有UI模式、平台目标）。在流程允许的情况下并行启动独立Agent（例如：阶段4的评审Agent可同时运行）。

Pipeline

流程步骤

Phase 1a: Context Gathering

阶段1a：上下文收集

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.

开始设计前，需读取并整合以下内容：

```
design/gdd/game-concept.md
```
—— 平台目标与目标受众
```
design/player-journey.md
```
—— 用户到达该界面时的状态与场景
所有与该功能相关的GDD UI需求章节
```
design/ux/interaction-patterns.md
```
—— 可复用的现有模式（无需重新设计）
```
design/accessibility-requirements.md
```
—— 已确定的无障碍等级（例如：基础级、增强级、完整级）

若
design/ux/interaction-patterns.md
不存在，需立即告知用户：

"interaction-patterns.md不存在——无现有模式可复用。"

随后使用

AskUserQuestion

提供选项：

(a) 先运行
```
/ux-design patterns
```
建立模式库，再继续流程
(b) 不依赖模式库继续——ui-programmer会将所有创建的模式视为新模式，并在完成后添加至新的
```
design/ux/interaction-patterns.md
```
文件

不得仅根据功能名称或GDD凭空假设模式。若用户选择(b)，需在阶段3明确指示ui-programmer将所有模式视为新模式，并在实现完成后记录至

design/ux/interaction-patterns.md

。在最终总结报告中注明模式库状态（已创建/缺失/已更新）。

为ux-designer撰写一份简短的上下文摘要：用户正在执行的操作、需求、约束条件，以及相关的现有模式。

Phase 1b: UX Spec Authoring

阶段1b：UX规范编写

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.

调用

/ux-design [feature name]

Skill，或直接委派给ux-designer，按照

ux-spec.md

模板生成

design/ux/[feature-name].md

文件。

若设计HUD界面，则使用

hud-design.md

模板替代

ux-spec.md

。

特殊情况说明：
针对HUD设计，调用
/ux-design
时需传入参数
argument: hud
（例如：
/ux-design hud
）。
对于交互模式库，需在项目启动时运行一次
/ux-design patterns
，后续阶段引入新模式时需更新该库。

输出：

design/ux/[feature-name].md

，需填写所有要求的规范章节。

Phase 1c: UX Review

阶段1c：UX评审

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.

规范完成后，调用

/ux-review design/ux/[feature-name].md

。

关卡要求：在获得APPROVED verdict前，不得进入阶段2。若verdict为NEEDS REVISION，ux-designer需解决指出的问题并重新运行评审。用户可明确接受NEEDS REVISION的风险并继续，但需先通过

AskUserQuestion

告知具体问题，再询问是否继续。

Phase 2: Visual Design

阶段2：视觉设计

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

委派给art-director：

完整评审UX规范（流程、线框图、交互模式、无障碍说明）——不仅限于线框图图片
应用美术规范中的视觉风格：色彩、排版、间距、动画样式
检查视觉设计是否符合无障碍合规性：验证色彩对比度，确保颜色并非状态的唯一标识（需通过形状、文字或图标强化）
明确美术流程所需的所有资产需求：指定尺寸的图标、背景纹理、字体、装饰元素——需提供精确的尺寸和格式要求
确保与已实现的现有UI界面一致性
输出：包含风格说明和资产清单的视觉设计规范

Phase 3: Implementation

阶段3：开发实现

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

开始实现前，启用engine UI specialist（来自

.claude/docs/technical-preferences.md

中Engine Specialists → UI Specialist部分），对UX规范和视觉设计规范进行引擎特定实现指导评审：

该界面应使用哪种引擎UI框架？（例如：Unity中的UI Toolkit vs UGUI，Godot中的Control节点vs CanvasLayer，Unreal中的UMG vs CommonUI）
针对提议的布局或交互模式，是否存在引擎特定的注意事项？
推荐的引擎组件/节点结构？
输出：引擎UI实现说明，在ui-programmer开始工作前交付

若未配置引擎，则跳过此步骤。

委派给ui-programmer：

按照UX规范和视觉设计规范实现UI
使用
design/ux/interaction-patterns.md
中的模式——不得重新设计已指定的模式。若某模式基本符合需求但需修改，需记录偏差并提交给ux-designer评审。
UI不得拥有或修改游戏状态——仅负责展示；所有用户操作需触发事件
所有文本需通过本地化系统处理——不得硬编码面向用户的字符串
支持两种输入方式（键盘/鼠标和游戏手柄）
根据
```
design/accessibility-requirements.md
```
中已确定的等级实现无障碍功能
绑定游戏状态数据
若实现过程中创建了新的交互模式（即模式库中未有的内容），需在标记实现完成前添加至
```
design/ux/interaction-patterns.md
```
输出：已实现的UI功能

Phase 4: Review (parallel)

阶段4：并行评审

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.

并行委派：

ux-designer：验证实现是否符合线框图和交互规范。测试仅键盘和仅游戏手柄的导航方式。检查无障碍功能是否正常工作。
art-director：验证与美术规范的视觉一致性。检查最小和最大支持分辨率下的显示效果。
accessibility-specialist：验证是否符合
```
design/accessibility-requirements.md
```
中记录的已确定无障碍等级。将任何违规情况标记为阻塞问题。

需等待三个评审流均完成报告后，才能进入阶段5。

Phase 5: Polish

阶段5：打磨优化

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)

解决所有评审反馈
验证动画是否可跳过，并尊重用户的减少动效偏好
确认UI音效通过音频事件系统触发（不得直接调用音频）
在所有支持的分辨率和宽高比下进行测试
验证
design/ux/interaction-patterns.md
是否更新至最新——若该功能实现过程中引入了新模式，确认已添加至库中
确认所有HUD元素符合
design/ux/hud.md
中定义的视觉预算（元素数量、屏幕区域分配、最大透明度值）

Quick Reference — When to Use Which Skill

快速参考——不同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

```
/ux-design
```
—— 从零开始为界面、流程或HUD编写新的UX规范
```
/ux-review
```
—— 在实现前验证已完成的UX规范
```
/team-ui [feature]
```
—— 从概念到打磨的完整流程（内部调用
```
/ux-design
```
和
```
/ux-review
```
）
```
/quick-design
```
—— 无需全新UX规范的小型UI修改

Error Recovery Protocol

错误恢复协议

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:

Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
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.
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
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

若任何通过Task启用的Agent返回BLOCKED、错误或无法完成任务：

立即告知用户：在继续后续依赖阶段前，向用户报告"[AgentName]: BLOCKED — [原因]"
评估依赖关系：检查被阻塞Agent的输出是否为后续阶段所需。若是，若无用户输入则不得越过该依赖点。
通过AskUserQuestion提供选项：
- 跳过该Agent并在最终报告中注明缺口
- 缩小范围重试
- 在此处停止并先解决阻塞问题
始终生成部分报告——输出已完成的所有内容。不得因单个Agent阻塞而丢弃已完成的工作。

常见阻塞情况：

输入文件缺失（未找到需求文档、GDD不存在）→ 重定向至创建该文件的Skill
ADR状态为Proposed → 不得实现；先运行
```
/architecture-decision
```
范围过大 → 通过
```
/create-stories
```
拆分为两个需求
ADR与需求文档存在冲突指令 → 告知用户冲突，不得自行猜测

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.

所有文件写入操作（UX规范、交互模式库更新、实现文件）均委派给子Agent和子Skill（

/ux-design

、ui-programmer）。每个Agent和Skill均执行"是否允许写入[路径]？"协议。本编排器不直接写入文件。

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.

一份总结报告，涵盖：UX规范状态、UX评审结果、视觉设计状态、实现状态、无障碍合规性、输入方式支持、交互模式库更新状态，以及任何未解决的问题。

Verdict：COMPLETE —— UI功能已通过完整流程交付（UX规范→视觉设计→开发实现→评审→打磨）。 Verdict：BLOCKED —— 流程暂停；停止前需告知用户阻塞问题及所在阶段。

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.

若最终规范尚未通过评审，运行
```
/ux-review
```
。
关闭需求前，对UI实现运行
```
/code-review
```
。
若需视觉或音频打磨，运行
```
/team-polish
```
。