ux-design

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,docs.density

已在上方解析——直接使用。没有配置块 → 使用 .claude/docs/config-resolution.md 中的默认值。

UX 设计

调用此技能时：

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终询问 · 引导模式仅询问重大事项 · 自主模式记录并继续； automation_always_ask 类别始终提示）。

编写指南：以下骨架均可独立使用——直接根据它们编写。需要深入内容的章节（示例、模式目录、无障碍标准），可查阅对应指南：

编写内容	指南
UX 规范	.claude/docs/templates/guidance/ux-spec-guide.md
HUD 设计	.claude/docs/templates/guidance/hud-design-guide.md
交互模式	.claude/docs/templates/guidance/interaction-pattern-library-guide.md（链接到三个主题文件）
无障碍要求	.claude/docs/templates/guidance/accessibility-requirements-guide.md

按章节加载指南，绝不加载整份指南——每份指南均按章节组织，模板中的指引会标明要阅读的确切章节。

workflow（参见 .claude/docs/workflow-modes.md）：

• full — 每个屏幕都必须编写 UX 规范。
• standard — 仅需编写核心屏幕（主菜单、HUD、主要游戏循环）。
• minimal — 无需编写。仍可自愿编写。

docs.density——它控制每个章节的深度，而 workflow 控制要编写规范的屏幕。modes.rigor 会同时设置两者；若只想调整深度，请显式设置 docs.density：terse（默认值，通过 rigor: minimal 设置）= 线框描述 + 交互要点；balanced = 线框 + 流程段落描述 （rigor: standard）；thorough = 完整的文字说明，包括用户研究摘要和 备选流程考量。对编写的每个章节都应用此设置。

1. 解析参数并确定模式

根据参数，共有四种编写模式：

参数	模式	输出文件
hud	HUD 设计	design/ux/hud.md
patterns	交互模式库	design/ux/interaction-patterns.md
accessibility	项目级无障碍要求	design/accessibility-requirements.md
其他任意值（例如 main-menu、inventory）	针对屏幕或流程的 UX 规范	design/ux/[argument].md
无参数	询问用户	（见下文）

**accessibility 是唯一会在 design/ux/ 之外写入文件的模式。**其 输出是项目级标准，供各屏幕规范参考，而非针对单个屏幕的规范——.claude/docs/workflow-catalog.yaml、预制作和 润色阶段门，以及 /architecture-review 都会检查 design/accessibility-requirements.md 这一确切路径。不要将其“整理”到 design/ux/ 下：所有这些检查都会无法匹配，技术设置 → 预制作阶段门也将无法通过。

如果未提供参数，不要报错，而应询问。使用 AskUserQuestion：

• “今天我们要设计什么？”
  • 选项：“特定屏幕或流程（我会命名）”、“游戏 HUD”、“交互模式库”、“项目级无障碍要求”、“我不确定——请帮我想想”

如果用户选择“我会命名”或输入屏幕名称，请将其规范化为 kebab-case 作为文件名（例如，“Main Menu”应变为 main-menu）。

---

2. 收集上下文（读取阶段）

现在阅读 references/2-gather-context.md 并遵循其中的说明——此阶段的步骤在该文件中，而非此处。如果此阶段期间对话被压缩或恢复，请重新阅读该文件。

3. 创建文件骨架

现在阅读 references/3-file-skeleton.md 并遵循其中的说明——此阶段的步骤在该文件中，而非此处。如果此阶段期间对话被压缩或恢复，请重新阅读该文件。

4. 逐节编写

现在阅读 references/4-authoring.md 并遵循其中的说明——本阶段的步骤在该文件中，而不是在这里。如果在本阶段期间对话被压缩或恢复，请再次阅读。

分节指南——只阅读与当前模式对应的文件

各模式的分节编写指南分别存放在各自的文件中。进入第 4 阶段时，只阅读第 1 节中确定的模式对应的文件；切勿加载另外两个文件。

模式	指南文件
UX 规范（屏幕或流程）	references/sections-ux-spec.md
HUD 设计	references/sections-hud.md
交互模式库	references/sections-patterns.md
无障碍要求	.claude/docs/templates/guidance/accessibility-requirements-guide.md

无障碍指南位于 templates/guidance/ 下，而非此技能的 references/ 目录中，因为其说明的模板（.claude/docs/templates/accessibility-requirements.md）也供 /ux-review 和门控文件使用。规则相同：只加载涵盖你正在编写的分节的部分，切勿加载整个文件。

将 docs.density（第 1 节）应用于该文件要求你编写的内容——它控制各分节的深度，而非决定哪些分节存在。

5. 交叉引用检查

现在阅读 references/5-crossref-handoff.md 并遵循其中的说明——本阶段的步骤在该文件中，而不是在这里。如果在本阶段期间对话被压缩或恢复，请再次阅读。

7. 恢复与续写

如果会话中断（上下文压缩、崩溃、新会话）：

1. 阅读 production/session-state/active.md——其中记录了当前屏幕以及已完成的分节。
2. 阅读 design/ux/[filename].md——包含实际内容的分节即为已完成；标记为 [To be designed] 的分节仍需处理。
3. 从下一个未完成的分节继续——无需重新讨论已完成的分节。

这就是增量编写的重要性：每个获批的分节都能在任何中断后保留下来。

---

8. 专家 Agent 路由

此技能将 ux-designer 用作主要 Agent（在 frontmatter 中设置）。针对特定子主题，可能需要额外的背景信息或协调：

主题	协调对象
视觉美感、色彩、布局观感	art-director——UX 规范定义区域；art 定义其呈现效果
实现可行性（引擎限制）	ui-programmer——定稿组件清单之前
游戏数据需求	game-designer——数据归属不明确时
UI 中展示的叙事／背景设定	narrative-director——用于风味文本、物品名称、背景设定面板
无障碍等级决策	由本次会话根据 accessibility-specialist 制定并审核的标准记录（/ux-design accessibility；由用户选择等级）——要求的判定标准不明确时请咨询该专家

通过 Agent 工具委派给其他 Agent 时：

• 提供：屏幕名称、游戏概念摘要、需要专家解答的具体问题
• Agent 将分析结果返回给本次会话
• 本次会话向用户呈现 Agent 的输出
• 用户做决定；本次会话写入文件
• Agent 不会直接写入文件——所有文件写入均由本次会话负责

---

协作协议

在 collaborative 模式下（默认模式）。 关于 guided 和 autonomous 模式，请参阅 .claude/docs/automation-modes.md 中各模式的规则——以下步骤说明的是协作模式的要求，并非普遍适用的规则。

此技能在每一步都遵循协作设计原则：

1. 提问 -> 选项 -> 决策 -> 草稿 -> 批准，适用于每个部分
2. 在每个决策点使用 AskUserQuestion（说明 -> 记录模式）：
   • 阶段 2：“准备开始了，还是需要更多背景信息？”
   • 阶段 3：“我可以创建框架吗？”
   • 阶段 4（每个部分）：设计问题、方案选项、草稿审批
   • 阶段 5：“运行交叉引用检查吗？接下来做什么？”
3. 在创建框架和撰写每个部分之前，询问“我可以写入 [filepath] 吗？”
4. 渐进式写入：每个部分获批后，立即写入文件
5. 更新会话状态：每次写入部分后更新

尊重审美偏好：当布局或视觉选择取决于个人品味时，列出选项并询问。不要因为某种布局是“标准”就自行选择——务必先确认。用户是创意总监。

明确呈现冲突：当 GDD 要求与可用屏幕空间发生冲突时，指出冲突并提供解决方案。绝不悄悄删减要求，也绝不在不说明的情况下扩大布局。

绝不自动生成完整规格并将其作为既成事实呈现。 绝不在未经用户批准的情况下撰写某个部分。 绝不在不指出冲突的情况下违背现有的已批准 UX 规格。 始终说明决策依据（GDD 要求、玩家旅程、用户选择）。

结论：完成——UX 规格已按部分撰写并逐一获批。

---

建议的后续步骤

• 运行 /ux-review [filename]，在此规格进入实施流程前对其进行验证
• 运行 /ux-design [next-screen]，继续设计其余屏幕或流程
• 所有关键屏幕的 UX 规格都获批后，运行 /gate-check production