跨域界面评审需要统一编排时，用 better-*…

适用于对屏幕、流程、功能或仓库界面执行跨无障碍、布局、文案、字体、色彩和 UI 的只读评审，并合并为一份带范围、证据、严重度和结论的报告。

适用场景

解决思路

1. 仅负责编排：将界面路由到每个 better-* 技能，收集它们的证据并合并成一份排序后的结论。
2. 不在此重复或覆盖各域规则：无障碍归 better-accessibility，结构归 better-layout，文案归 better-writing，字体归 better-typography，色彩归 better-colors，视觉润色与动效归 better-ui。
3. 对未提交工作、分支和 pull request 的变更范围评审交给 interface-review，由它解析范围并分类 findings 后再交回。
4. 以证据而非品味为准：严格执行升级触发条件，保留项目有意的选择；触发条件无论风格指南怎么写都是失败；仅仅不喜欢的密度、圆角或声音不是 finding。
5. 报告门槛是证据，不是品味；Approve 门槛是确实检查了你声称检查的内容；简短的真实检查报告优于长篇注水。
6. 先解析范围：从请求和当前工作区推断 screen、flow、feature 或 repository 范围，并在输出中声明解析后的范围。
7. 覆盖所有域技能，包括存在的 empty、loading、error 和 narrow-width 状态；最多报告 15 个 findings。
8. 当范围大到无法可信检查时，缩小到一个完整流程：请求中心的流程，或所有用户必经的入口路径；声明边界和排除内容；绝不暗示未检查表面已评审。
9. 将变更请求交给 interface-review：请求命名 branch、pull request、commit range 或未提交更改时，说明这是变更评审而非屏幕评审，并让用户运行 interface-review（由用户调用，不能从这里启动）。
10. 绝不在此解析变更范围：读取 diff、分类 findings、将变更文件扩展到受影响表面属于 interface-review；猜测会导致无人可核验的范围。
11. 当 interface-review 交回评审时，使用它提供的变更范围、每个 finding 的状态和变更范围报告格式；Severity、ranking、cap 和 verdict 留在这里，且三者只覆盖 Introduced 和 Regression。
12. 判断前先侦察：识别框架、样式系统、组件库、设计令牌、支持的视口以及任何预览或测试命令。
13. 用项目自身习惯写每个修复，使 finding 不变成要求采用不同技术栈；这管修复形式，不管代码是否足够好。
14. 阅读项目关于自身界面的文档：CONTRIBUTING.md、CODING_STANDARDS.md、AGENTS.md、CLAUDE.md、design-system doc、Storybook docs、interface ADRs；说明找到了哪些，或没有。
15. 阅读这些文档是为了确定 finding 归属，不是获得丢弃许可；文档化约定不能证明约定好，在风格指南里不能撤销 finding；它们改变的是报告位置；当指南或共享 token 是原因时，针对该源报告一次，组件作为其位置。
16. 评审前确认每个 owning skill 可用；加载并应用每个可用 owner，完成每个域评审后再整合。
17. 按顺序评审：better-accessibility、better-layout、better-writing、better-typography、better-colors、better-ui，以免基础失败被润色掩盖。
18. 从加载的域技能取原则、引用和验证检查；其 severity ladder 和格式用于独立使用；本文件的整合格式、共享 severity 和 finding cap 替换它们。
19. 如果 owning skill 不可用，将该域标记为 Not reviewed，命名它并继续；不要凭记忆重建规则、替代邻居或声称整体覆盖。
20. 当两个技能似乎覆盖一个问题时，将其分配给底层规则的 owner，并在 Why 单元格注明次要影响；只报告一次。
21. 要求证据：每个 finding 引用 path/to/file:line 并展示当前实现。
22. 不要仅凭视觉外观报告代码级 finding，或仅凭源码报告视觉 finding；当运行时行为决定结果时尤其如此。
23. 按用户影响排名：使用共享严重度等级 HIGH：阻塞任务、误导用户、隐藏内容或控件、造成数据丢失风险、或造成重复系统性失败；MEDIUM：有意义地损害理解、效率、适应性或一致性；LOW：孤立润色，任务影响有限。
24. 在同一严重度内，按 finding 触及多少地方和一次修复收益排名；token 或共享组件修复排名高于单个叶子相同症状。
25. 执行升级触发条件：一旦 owning skill 确认以下之一，即 HIGH，绝不因表面次要而降级：无 accessible name 的交互控件；键盘可达控件无可见焦点指示；指针可达但键盘不可达的控件或路径；动效或自动播放忽略 prefers-reduced-motion；内容或控件在 320px 宽或 200% 缩放下被裁剪、重叠或不可达；正文或控件文本渲染对比度对不满足所需比率；状态或含义仅由颜色传达；破坏性操作无确认、撤销或区别处理；截断内容无法访问完整值；内容或控件只能通过滚动边缘或没有可见提示的展开访问；错误未说明恢复方式；语义颜色与含义相悖（如危险色用于非破坏性操作）；状态变化仅由动效传达，动画不运行时没有颜色、图标或标签留下。
26. 触发条件排名高于所有其他 finding；当触发条件超过 cap，先列出它们并说明 cap 排除了多少；cap 可以缩短报告，但绝不能成为 blocker 未报告的原因。
27. 这些触发条件设定 severity，不是新规则；owning skill 决定症状是否存在，此列表决定代价；在变更审查中，确认的 Regression 对触发条件是 HIGH，即使同样症状作为预先存在会是 MEDIUM。
28. 优先更便宜的修复：当多个修复可行时，取最早可行的：1. Delete：删除空格能承载的分隔符、高频交互上的动画、原生元素使冗余的 ARIA 属性、没有导入的 ramp。2. Use the platform：用原生元素、原生控件、浏览器自己的焦点环，代替自定义重建。3. Reuse what the project has：用现有 token、间距步骤或动效曲线，先于任何新值。4. Correct the value：修正错误的缓动、圆角、间距或对比度对，使用 owning skill 给的确切值。5. Add：新增 token、包装器、媒体查询、平台无法提供的 ARIA 属性。
29. 在步骤 1 可用时写成步骤 5 的修复本身就是 finding；报告删除。
30. 合并系统性 findings：一个根因是一个 finding；在同一行列出每个确认位置，而不是每次出现一行。
31. 绝不为达到 cap 而填充；短评审或无 findings 是有效结果。
32. 验证可验证的内容：运行项目提供的安全、相关检查。
33. 当运行时行为或视觉判断重要时检查渲染界面，并报告确切命令或交互及结果。
34. 无法运行的检查是 Not verified，绝不是 finding。
35. 默认不修改地评审：把评审请求当作只读；除非用户也要求实现 findings，否则不要编辑源码。
36. 当用户要求实现时，保持整合报告作为变更范围，并随后重新运行相关验证。
37. 避免六个不连接域报告：合并成一个排名 findings 表。
38. 避免仅从源码推断视觉声明：检查渲染状态，或标记未验证。
39. 避免覆盖静默缺口：显示实际检查了哪些域和状态。
40. 避免缺失 owning skill 被当作已覆盖：标记域 Not reviewed 并命名 skill。
41. 避免报告触碰文件中每个遗留问题：三个预先存在 findings，放在自己部分。
42. 避免预先存在问题阻塞变更审查：将预先存在 findings 排除在 cap 和 verdict 之外。
43. 避免域被标记 Clear 当变更从未触及：标记 Not reviewed: no evidence in the change scope。
44. 按 review-format.md 输出：scope and coverage、findings table、verification 和 verdict；评审未完成直到 findings 报告在那里。

适用边界 · 注意事项

• 请求涉及 branch、pull request、commit range 或未提交更改的变更范围评审时，不适用；应交给 interface-review。
• 当某个 owning skill（如 better-accessibility、better-layout 等）不可用时，该域不适用在此评审；标记 Not reviewed，不要凭记忆重建规则。
• 范围大到无法可信检查时，不适用全范围评审；缩小到一个完整流程，或明确声明未检查表面。