关于 ui-review
ui-review 是一套界面审查流程，依据不同尺寸的渲染截图、交互探测和编号标准评估页面。它指导审查者从范围界定和代码检查，到整理证据并给出发布结论。
主要功能
- 01检查多个宽度下的页面截图
- 02运行项目代码检查与无障碍扫描
- 03探测键盘、焦点、加载和错误状态
- 04按标准和证据排序问题
- 05记录覆盖范围与发布结论
适用场景
- 01发布前审查变更页面
- 02检查响应式布局和键盘操作
- 03记录可复现的界面问题
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/ui-review确认已加载。
附带文件references/criteria.md
详细介绍
UI 审查
渲染结果就是证据。描述、DOM 文本或源代码只能作为辅助。严重级别、13 项标准和边缘情况见 references/criteria.md。如果已安装的设计系统有自己的规则，应优先采用，并将其视为双方认可的标准。
步骤
- 确定范围。 优先采用调用方指定的范围；否则采用分支中已更改的屏幕；再否则检查排名前五的路由。
- Lint。 对范围内的文件运行项目自带的 lint。记录命令和退出代码。
- 捕获。 在每种宽度下（默认使用应用的最窄和最宽宽度，以及 390 和 1280），为每个屏幕捕获重要状态；每种宽度都要重新导航一次。安装了
build-design-system时，build-design-system/scripts/capture.mjs会在保护机制下完成此操作，阻止所有写入，并保存每次捕获的无障碍树。它需要--writes <file>，其中列出应用的写入操作；或使用--no-backend。它只会写入自己的--out文件夹（请将其放在.ui-review/下）。否则，使用宿主提供的浏览器工具，并自行保存无障碍树。如果项目有无障碍扫描器，也要运行。 - 用一行话说明每个屏幕的用途。 如果调用方没有说明，则标记为假设。
- **在本地构建中检查每个屏幕的陷阱：**键盘操作路径、关闭后焦点位置、加载和错误状态、限速标签页、减少动态效果，以及触控宽度。每项检查都要记录测量结果，或说明未运行的原因。使用 Event Timing API 测量按下反馈（通过
PerformanceObserver监听event条目，每项duration都低于 100 ms）。不要点击任何会写入共享数据的内容。 - 按每种宽度逐项检查标准。 每项发现都要引用编号和名称，或已安装规则的 ID。
- 排序。 如果有多位审查者（组成评审组），给每个人相同的提示词，不指定角色，并要求只读审查。协调者随后将每项发现归入
blocking、should-fix、note或dismissed，注明提出者并给出一行理由。两位审查者独立提出同一问题，是最强信号。忽略吹毛求疵、没人追溯到实际调用位置的假设，以及“我会用别的方式做”。在同一类别中，先列出会写入数据的界面，再按受影响的位置排序。没有评审组时，独自完成同样的工作。 - 逐项检查边缘情况，并标记每项是否已展示。
- 最后撰写结论。
规则
- 每项发现都必须包含一项标准、可查找的位置（元素的角色和名称，以及对应的捕获文件，例如
button 'Save changes' (settings-1280.png)）、宽度和证据。基于个人喜好的发现应舍弃并列入“未纳入”。 - 错误示例：“间距看起来太紧。” 正确示例：“标签与自身字段相距 24 px，与下一个字段相距 8 px（标准 4，settings-390.png）。”
- 推断得出的发现应写成能够验证该问题的检查。推断得出的
blocking发现应使结论为no, pending <the check>。 - 声称某项功能正常或已修复时，必须注明本次会话中的命令或捕获文件。
- 对比度、目标尺寸和键盘问题应标注优先级。仅增加语义的无障碍树变更应标注优先级。移除或重构语义的变更应交由人员处理。
- 基于截图得出的输入响应性（标准 13）发现或通过结论无效；必须通过测量检查。焦点环则相反：通过实际按 Tab 键到达控件，并根据捕获结果判断焦点环，因为通过
:has(:focus-visible)绘制焦点环的容器会导致焦点元素报告没有轮廓。 - 修复背后的产品决策应交由人员决定。保留用户输入这一点则始终不需要。
输出
第一行用通俗语言回答请求。随后给出交付行：Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2, 3 questions for a person). 任何 blocking 发现都会让结论变为 no；推断出的发现会让结论变为 no, pending <the check>；只有 should-fix 时，结论为 yes, with fixes；只有备注时，结论为 yes。
然后按顺序给出：
- 评审记录。 来源、工具、宽度、日期、标准文件、标明为已提供或假设的目的，以及所有假设和缺漏。
- 发现，按类别排列；每项包括提出者、观察到的情况、位置、标准、此处的重要性、证据，以及以当前构建无法通过的检查形式描述的修复项（
Fix Enter in Email so that it sends 1 POST）。 - 未展示的边缘情况。 每项一行。
- 由人决定。
- 已驳回和未纳入的事项。 每项注明提出者和原因。
独立运行，并将报告保存到 .ui-review/<date>-<flow>.md，截图放在同一目录中。协调者只要求截图时，返回截图路径、宽度和 Coverage: 行，不附带任何发现。聊天回复应包含回答行和交付行、每条命令及其退出代码，以及一条可由用户粘贴以继续下一步的提示词。
完成标准
每项发现都有标准、位置、证据，并且只标明显示该问题的宽度。每项探测都有结果或说明原因。第一行、交付行和摘要相互一致。最后一行以 Coverage: 开头，列出已测量的路由、宽度、主题和探测，然后注明尚未覆盖的内容。