better-interface

把界面作为一个整体系统进行审查

优秀的界面绝不是把六项独立的审查硬拼凑在一起。应当审查完整的体验，让每个 better-* Skill 各司其职、把控其专业领域的规则，再将所有证据汇总并提炼出一份按优先级排序的最终结论。

本 Skill 仅负责整体调配与统筹。无障碍规则归 better-accessibility；布局与结构归 better-layout；文案归 better-writing；字体与排版归 better-typography；色彩归 better-colors；视觉细节与动效归 better-ui。切勿在此重复或覆盖各自领域的规则。

核心原则

1. 先明确审查范围与模式

根据用户请求和当前工作区，推断待审查的页面、流程、功能或仓库范围。在输出结果中明确说明确定的范围。若未指定模式，默认使用 full（完整模式）。

模式	覆盖范围	问题数量上限
quick	核心用户路径及最高频状态；仅报告 HIGH 和 MEDIUM 级别的问题	5
full	请求范围内的所有内容，跨全部六个领域 Skill，包含现有的空白页、加载中、错误页及窄屏状态	15

如果请求审查的范围过大，无法做出可靠严谨的检查，应将其收拢至流量最高的一条完整流程，并明确说明边界。绝对不能暗示未检查的区域也已审查过。

2. 审查前先侦察项目背景

明确项目使用的前端框架、样式系统、组件库、设计 Token、支持的视口尺寸，以及可用的预览或测试命令。遵循项目既有的 Tailwind、原生 CSS、CSS-in-JS、Token 与组件规范。

3. 以各领域 Skill 为唯一事实来源

开始审查前，先确认以下全部六个所属 Skill 均可用。加载并应用所有可用的领域 Skill。在 quick 模式下，检查全部六个领域，但仅在核心流程有明确证据的地方展开深入；在 full 模式下，完成每个可用领域的审查后再进行汇总。

按以下顺序依次审查，避免基础性缺陷被视觉细节掩盖：

1. better-accessibility
2. better-layout
3. better-writing
4. better-typography
5. better-colors
6. better-ui

本 Skill 掌握最终的输出回应。当某个领域 Skill 通过 better-interface 被调起时，请应用其核心原则与参考标准，但忽略其单打独斗时的审查输出格式。统一使用本文件定义的汇总格式、共享严重性标准和问题数量上限。

若某个所属 Skill 不可用，将该领域标注为 Not reviewed，列出缺失的 Skill 名称，并继续审查其余领域。切勿凭记忆凭空补充规则、用相近 Skill 替代，或虚报全盘覆盖。

当两个 Skill 似乎覆盖了同一个问题时，将其归属于掌控底层规则的那个 Skill，并在 Why 列中说明次要影响。只报告一次该问题。

4. 讲求证据，逢评必查

每一条发现的问题都必须注明 path/to/file:line 并展示当前实现代码。如果审查对象没有源文件，须引用具体的页面和组件名称。当最终结果取决于运行时行为时，切勿仅凭视觉外观就判定代码层面的问题，或仅凭源码就判定视觉层面的问题。

5. 按照对用户的影响排序

统一使用一套共享的严重性分级标准：

• HIGH：阻碍任务完成、误导用户、隐藏关键内容或控件、存在数据丢失风险，或引发重复出现的系统性故障。
• MEDIUM：显著损害易理解性、操作效率、响应适配性或整体一致性。
• LOW：影响有限的局部打磨问题。仅在 full 模式下包含。

在同一严重性级别内，按影响面（Reach）和杠杆率（Leverage）排序。修复一个全局 Token 或共享组件的问题，优先级高于单点叶子组件中的相同症状。

6. 归并系统性问题

一个根因对应一条问题记录。将所有已确认的发生位置列在同一行中，而不是按出现次数重复分行。不要为了凑满问题上限而硬塞内容；没有发现问题或简短的审查报告同样是有效结果。

7. 显性展示克制

记录下审查过程中考虑过但被主动否决的改进方案。被否决的合理原因包括：所属 Skill 允许当前实现、证据不足、属于项目既定的有意设计、或者拟议的修改只会增加复杂度而无法为用户带来实际收益。

8. 能验证的必须验证

运行项目里现成且安全的检查命令。当涉及运行时行为或视觉呈现时，应实际检查渲染出来的界面。报告具体的命令或交互步骤以及观察到的结果。如果某个检查无法执行，请标注为 Not verified 并说明遗留事项；绝不能把验证空白直接当作缺陷问题来报告。

9. 默认只读审查，不改动代码

将审查请求默认视为只读操作。除非用户明确要求修改并实现，否则不要直接编辑源代码。当用户要求实施修改时，以汇总报告作为改动范围，并在修改后重新运行相关的验证步骤。

常见误区

误区	正确做法
输出了六份相互割裂的领域报告	汇总为一张统一按优先级排序的问题表格
多个 Skill 重复报告同一个问题	划归给掌控底层规则的那个 Skill
问题没有标注具体位置	引用 path/to/file:line 并附上当前代码实现
仅凭源码推断视觉外观问题	检查实际渲染状态，或标注为未验证
无节制地罗列低影响微调点	遵守模式的上限要求；在 quick 模式下直接省略 LOW 问题
审查覆盖范围存在隐瞒或遗漏	明确展示实际检查了哪些领域和状态
缺失所属 Skill 却假装已覆盖	将该领域标注为 Not reviewed 并给出缺失的 Skill 名称
没有输出被否决的提案列表	按要求提供“考虑过但被否决”的表格
审查过程中静默修改了代码	保持只读，除非用户明确要求实现修改
在仍有待处理缺陷时给出“Approve”	选用 Needs changes 或 Block

审查输出格式

请始终包含以下章节。

范围与覆盖情况

说明审查模式、确切范围、技术栈与样式规范，以及任何审查边界。随后展示覆盖情况：

领域	已检查证据	审查结果
Accessibility	文件、组件、状态或检查项	问题数量或 Clear

须包含全部六个领域。Clear 表示已检查且无需要处理的问题；标注 Not reviewed 时必须说明原因。

问题清单（Findings）

使用一张统一表格，先按严重性排序，再按影响面和杠杆率排序：

#	严重性	领域	位置	修改前	修改后	原由（Why）
1	HIGH	Accessibility	src/Dialog.tsx:42	<button><XIcon /></button>	添加 aria-label="Close" 并将图标从无障碍树中隐藏	纯图标控件缺失无障碍名称

每行代表一个根本原因。领域列填入所属 Skill 去掉 better- 前缀后的名称。严格遵守对应模式的问题数量上限。若无问题，省略表格并注明“无需要处理的界面问题。”

考虑过但被否决的提案（Considered but Rejected）

在 quick 模式下包含 1–3 个提案，在 full 模式下包含 2–5 个提案：

位置	备选提案	否决原因
src/Card.tsx:28	加深阴影	现有深度符合全局 Surface Token 规范；仅修改单个卡片会破坏一致性

这些必须是审查过程中真实评估过的候选点，而非凭空编造的凑数项。如果范围较小确实没有那么多临界候选点，如实列出存在的即可并作说明。

验证情况（Verification）

列出每一个检查项或交互步骤、具体的命令或操作步骤以及观察到的结果。将已通过的检查与标注为 Not verified 的项区分开。

结论（Verdict）

末尾必须严格输出以下三者之一：

• Block — 仍存在一个或多个 HIGH 级别的问题。
• Needs changes — 仅存在 MEDIUM 或 LOW 级别的问题。
• Approve — 无待处理问题，且声明的覆盖范围已全部完成验证。