ultrahand: review
像专家检查员一样审查 UI 设计。逐一检查每个流程、交互和控件，对照平台原则、尼尔森 10 条启发式和 WCAG 2.2 AA 标准，然后验证设计在其他尺寸下是否依然成立。输出结果是一份按严重性排序的问题清单。每个问题都指明元素、所违反的原则及其来源，并提供具体的修复方案。
所有检查项均在 references/checklist.md 中，每条检查项都引用了 references/sources.md。有关平台规则的详细信息，请使用设计技能自身的原理原则：
mobile、
tablet 和
desktop。
对于有主题的项目，请使用 theme-review 技能对照主题进行设计检查：令牌使用、组件复用以及跨屏幕一致性是其职责，而不是此技能的。
1. 获取设计并了解其可以展示的内容
使用用户能够提供的最丰富的证据。说明你拥有的证据类型，因为它限制了你能够确认的内容。
- ultrahand canvas 制品（一个 claude.ai 制品链接）：读取其 HTML。它包含标记、标签、颜色、每个界面和状态。如果浏览器工具可用，请打开制品。通过
window.ultrahandCanvas（参见shared/canvas/中的 canvas 说明）设置每种视图：usePreset(id)、setSize(w, h)、setScheme('dark')、setTextScale(2)、setState('error')、navigate(id)。打开 显示点击目标 并读取其结果（#uh-targets-result），该结果会统计低于平台最小尺寸的目标数量。打开面板或菜单后调用refresh()，以便统计包含这些元素的结果。canvas 说明列出了工具栏的元素 ID。原型中的桩（无真实网络、无屏幕键盘）归类为 未检查，不属于问题清单。硬件键盘是真实的：使用它驱动每个流程。 - 本地 canvas 构建（来自
build.mjs的index.html）或任何你可以打开的页面：将其视为制品，并与输入驱动程序（步骤 4）一起使用。 - 代码（HTML、SwiftUI、Compose、Flutter 等）：你可以检查标签、角色、焦点顺序、颜色和断点，但除非可以运行，否则无法检查其外观。
- 截图或模型： 你可以判断布局、层次结构、措辞以及近似的对比度和尺寸。无法确认标签、焦点顺序或行为；将这些发现标记为 Likely 或将其列在 未检查 之下。
标记每个发现的证据类型：Confirmed（在代码中看到或在 canvas 上测量得到）或 Likely（从图像推断得出）。切勿将关于隐藏行为的猜测作为事实呈现。
2. 建立上下文
在评判任何内容之前，请先记录以下内容；只有基于这些上下文，发现才有意义。
- 平台： iOS、iPadOS、Android、macOS、Windows 或 Web。从 canvas（
size.platform）、代码或视觉风格中读取。如果不清楚，请询问一次。 - 当前尺寸： 宽 × 高，以及宽度尺寸类别：紧凑 < 600、中等 600–839、扩展 840–1199、大 1200–1599、超大 1600+。高度紧凑 < 480、中等 480–899、扩展 900+。注意方向以及是否分屏。
- 输入方式： 触摸、指针、键盘或混合。平板或触摸屏笔记本可能具备所有三种输入方式。
- 用户和主要任务： 每个界面供谁使用，以及其主要目的。如果无法推断，请询问；没有任务的审查会变成意见清单。
- 产品或工具： 面向最终用户的设计，或是为所有者构建的工具（canvas 本身、编辑器、查看器）。工具是一个桌面应用程序，在任何尺寸的浏览器窗口中使用：请使用桌面规则进行审查并通过第 8 步。其框架需要经过第 7 步（在第 8 步中列出）的检查（窗口尺寸、浏览器缩放、自身主题），并像任何界面一样进行构图检查。
根据 窗口尺寸类别和输入方式 选择平台规则，而不是根据设备名称：紧凑型触摸 → 移动端原则；中等和扩展型触摸，或任何分屏 → 平板；带指针和键盘的窗口 → 桌面。响应式设计将覆盖其尺寸所涵盖的所有规则集。
3. 盘点设计
列出每个界面和状态、界面间的每个流程、每个界面的 区域（工具栏及其分组、窗格、窗格标题、表单组、卡片、列表、栏），以及每个区域中的每个交互式控件（按钮、链接、字段、开关、选项卡、菜单、手势、拖放目标）。盘点清单是审查的覆盖范围：未列出的区域或控件就是你未检查的部分。
在三个层面进行审查： 整个界面、每个区域和每个组件。一个每个控件都通过检查的界面仍然可能显得杂乱、无序和令人困惑；这本身就是一个发现，而不是细节打磨。
4. 按步骤检查
按顺序执行 references/checklist.md 中的步骤。将设计检查两遍：一次用于熟悉，一次用于发现问题。
使用真实输入、在多种尺寸下操作每个控件。 阅读标记，或调用 el.click()、dispatchEvent 或 setter，会跳过命中测试、焦点、默认操作和滚动链接，因此被遮挡的按钮或陷入循环的滚轮看起来仍然正常。像用户一样使用页面：通过来自 node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" 的可信鼠标、滚轮、键盘和触摸事件（其 README 包含步骤和示例），或使用浏览器工具的真实点击和按键。脚本仅用于设置视图并随后读取状态。
- 在至少三种尺寸下执行：最大尺寸、中等尺寸和最小支持尺寸（对于设计，使用其预设；对于工具，使用浏览器窗口，例如 1440×900、1024×700 和 640×480）。
- 在每种尺寸下，列出控件（
controls），然后按照每种控件应有的方式使用每个控件：点击或轻触、输入、拖动并用 Esc 取消、右键单击、使用键盘打开和关闭，以及在每个滚动器上超出其边界滚动或滑动。 - 少数原生控件无法在无头模式下使用可信输入驱动：如 select 的弹出菜单、文件选择器以及颜色和日期选择器。使用驱动程序的
choose步骤选择 select 的选项，并将其余控件列在 未检查 下。 - 读取每个结果：
covered表示控件被遮挡、无法到达或缺少某个尺寸；scrolled表示滚轮陷入循环；焦点丢失到body；页面错误。每个结果在该尺寸下都是一个发现。
- 任务演练： 对于每个流程，在每一步询问四个认知走查问题。
- 构图： 将每个界面作为一个整体，然后检查每个区域，对照构图规则（shared/composition/principles.md）。在最大和最小尺寸下运行其审核，并首先阅读模糊截图，然后再查看任何特定控件。审查修订时，还要将其与先前版本进行比较：本轮增加了什么，界面是否因此变得更加杂乱？
- 逐控件检查： 清单中的每个控件对照控件检查项。
- 启发式评估： 每个界面对照尼尔森 10 条启发式。
- 无障碍： WCAG 2.2 AA。计算对比度；不要仅凭目测。
- 平台规范： 步骤 2 中确定的平台和尺寸类别的规则。
- 尺寸变化和变体： 每个预设、分屏宽度、320 宽度的重排、200% 文字、深色模式、每个数据状态，以及在触摸设备上的两种方向和外接键盘状态（桌面窗口不会旋转：改为检查最小、最大和较短窗口）。
- 工具： 对于为所有者构建的工具，工作内容在任何窗口尺寸下都保持可见，舞台可以扩展到其边缘之外，缩放有极限，并且快捷键和拖放行为正常。
发现问题时立即记录，包括观察到问题的位置（界面 › 元素，以及尺寸、配色方案和状态）。一个在多个位置出现的问题是一个发现，但有多个位置。
5. 评定严重性
使用尼尔森 0–4 级量表。衡量有多少用户会遇到该问题、问题对他们的影响程度，以及用户了解问题后是否仍会持续受到影响。请参阅检查清单的严重性指南。
| 评级 | 含义 |
|---|---|
| 4 灾难性 | 阻止用户完成任务，或导致数据丢失。发布前修复。 |
| 3 严重 | 减慢或困惑许多用户，或在主要流程上未通过 WCAG AA。尽快修复。 |
| 2 轻微 | 减慢部分用户，或存在明显的变通方法。 |
| 1 美观性 | 打磨优化。有时间就修复。 |
不要报告评级 0。WCAG AA 失败永远不会低于 2。
6. 报告
以一段总结开头：使用的平台、审查的尺寸、你拥有的证据、第一印象（模糊截图显示的内容，界面看起来是有序还是杂乱）、按严重性分类的数量，以及最严重的问题。将与无序的主要界面相关的问题与 bug 同等重要地衡量：它会影响每一次使用，而不仅仅是某一条路径。然后按严重性从高到低列出问题，在同一严重性下按流程顺序排列，使用检查清单中的模板：
- ID 和严重性，例如
R3 · 3 Major - 元素： 界面 › 区域 › 元素（如果是构图问题，则为界面 › 区域或整个界面），以及显示问题的尺寸、配色方案或状态
- 证据： Confirmed（已确认）或 Likely（可能）
- 问题： 用户遇到了什么问题，用一两句话描述
- 原则： 违反的规则，以及其来源键（
WCAG 1.4.3、NNG-H4、tablet:AND-T2） - 修复： 具体的更改，包含数值（例如
将标签颜色提升至 #595959 以实现 7.0:1 对比度，而不是提高对比度）
以正面评价结尾（保持简短）、无法检查的内容及原因（屏幕阅读器输出、真实设备、动画），并注明单个审查员可能会遗漏其他人能发现的问题，因此值得进行第二人审查或可用性测试。
如果报告将发送给其他人，请主动提出将其发布为制品。并提议使用匹配的 ultrahand 设计技能来应用修复。