better-interface

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review the interface as one system

将界面作为一个系统进行评审

A strong interface is not six independent audits stapled together. Review the whole experience, let each

better-*

skill own its domain rules, then consolidate the evidence into one prioritized verdict.

This skill owns orchestration only. Accessibility rules belong to

better-accessibility

; structure to

better-layout

; copy to

better-writing

; type to

better-typography

; color to

better-colors

; visual polish and motion to

better-ui

. Never duplicate or override their rules here.

优秀的界面不是六个独立审计的简单拼接。要评审完整的用户体验，让每个

better-*

技能负责其领域规则，再将所有证据整合为一份按优先级排序的评审结论。

本技能仅负责协调统筹。可访问性规则归

better-accessibility

所有；布局结构归

better-layout

；文案内容归

better-writing

；排版归

better-typography

；色彩归

better-colors

；视觉润色与动效归

better-ui

。请勿在此处重复或覆盖这些技能的规则。

Core Principles

核心原则

1. Resolve Scope and Mode First

1. 先确定范围与模式

Infer the screen, flow, feature, or repository scope from the request and current workspace. State the resolved scope in the output. Use

full

when no mode is supplied.

Mode	Coverage	Finding cap
`quick`	Primary user path and highest-traffic states; report only `HIGH` and `MEDIUM` issues	5
`full`	Entire requested scope across all six domain skills, including empty, loading, error, and narrow-width states when present	15

If the requested scope is too large to inspect credibly, narrow it to the highest-traffic complete flow and state the boundary. Never imply uninspected surfaces were reviewed.

从用户请求和当前工作区推断评审的屏幕、流程、功能或代码库范围，并在输出中明确说明。若未指定模式，默认使用

full

模式。

模式	覆盖范围	问题数量上限
`quick`	主要用户路径和流量最高的状态；仅报告 `HIGH` 和 `MEDIUM` 级问题	5
`full`	涵盖所有六个领域技能的请求范围，包括空状态、加载状态、错误状态和窄屏状态（若存在）	15

若请求的范围过大，无法可靠检查，则将范围缩小至流量最高的完整流程，并明确说明边界。绝不能暗示未检查的界面已完成评审。

2. Recon Before Judgment

2. 评审前先调研

Identify the framework, styling system, component library, design tokens, supported viewports, and available preview or test commands. Follow the project's established Tailwind, plain CSS, CSS-in-JS, token, and component conventions.

确定项目使用的框架、样式系统、组件库、设计令牌、支持的视口，以及可用的预览或测试命令。遵循项目已有的Tailwind、纯CSS、CSS-in-JS、令牌和组件约定。

3. Use Domain Skills as the Sources of Truth

3. 以领域技能为事实依据

Load and apply the six owning skills. In

quick

mode, inspect all six domains but spend depth only where the primary flow has evidence. In

full

mode, complete each domain review before consolidation.

Review in this order so foundational failures are not hidden by polish:

```
better-accessibility
```
```
better-layout
```
```
better-writing
```
```
better-typography
```
```
better-colors
```
```
better-ui
```

When two skills appear to cover the same issue, assign it to the skill that owns the underlying rule and mention secondary effects in the Why cell. Report it once.

加载并应用六个领域技能。在

quick

模式下，检查所有六个领域，但仅在主要路径有相关证据时深入评审；在

full

模式下，完成每个领域的评审后再进行整合。

按以下顺序评审，避免基础问题被表面润色掩盖：

```
better-accessibility
```
```
better-layout
```
```
better-writing
```
```
better-typography
```
```
better-colors
```
```
better-ui
```

当两个技能看似涉及同一问题时，将问题分配给拥有底层规则的技能，并在原因栏中提及次要影响。每个问题仅报告一次。

4. Require Evidence

4. 需提供证据

Every finding cites

path/to/file:line

and shows the current implementation. If the review artifact has no source files, cite the exact screen and component. Do not report a code-level finding from visual appearance alone or a visual finding from source code alone when runtime behavior determines the result.

每个问题都需标注

path/to/file:line

并展示当前实现。若评审工件无源代码，则标注具体屏幕和组件名称。仅通过视觉外观推断代码层面的问题，或仅通过源代码推断视觉问题（当运行时行为决定结果时），均不允许。

5. Rank by User Impact

5. 按用户影响程度排序

Use one shared severity scale:

```
HIGH
```
: blocks a task, misleads the user, hides content or controls, causes data-loss risk, or creates a repeated systemic failure.
```
MEDIUM
```
: meaningfully harms comprehension, efficiency, adaptability, or consistency.
```
LOW
```
: isolated polish with limited task impact. Include only in
```
full
```
mode.

Within a severity, rank by reach and leverage. A token or shared-component fix outranks the same symptom in one leaf component.

使用统一的严重程度等级：

```
HIGH
```
：阻碍任务完成、误导用户、隐藏内容或控件、存在数据丢失风险，或造成反复出现的系统性故障。
```
MEDIUM
```
：对理解、效率、适应性或一致性造成显著负面影响。
```
LOW
```
：孤立的细节优化，对任务影响有限。仅在
```
full
```
模式下包含此类问题。

同一严重等级内，按影响范围和修复价值排序。修复令牌或共享组件的问题优先级高于单个叶子组件中的相同问题。

6. Consolidate Systemic Findings

6. 整合系统性问题

One root cause is one finding. List every confirmed location in the same row rather than producing a row per occurrence. Do not pad the report to reach the finding cap; a short review or no findings is a valid result.

一个根本原因对应一个问题条目。将所有确认的位置列在同一行中，而非每个位置单独一行。请勿为达到问题数量上限而凑数；简短的评审或无问题的结果均属有效。

7. Make Restraint Visible

7. 明确说明未采纳的候选方案

Record candidates considered but deliberately rejected. A candidate is rejected when the owning skill permits the current implementation, evidence is insufficient, the project convention is intentional, or the proposed change would add complexity without user benefit.

记录被考虑但故意否决的候选方案。当对应领域技能允许当前实现、证据不足、项目约定是有意为之，或提议的变更会增加复杂度却无用户收益时，否决候选方案。

8. Verify What Can Be Verified

8. 验证可验证的内容

Run safe, relevant checks available in the project. Inspect the rendered interface when runtime behavior or visual judgment matters. Report the exact command or interaction and observed result. If a check cannot be run, label it Not verified and state what remains; never convert a verification gap into a finding.

运行项目中可用的安全、相关检查。当运行时行为或视觉判断至关重要时，检查渲染后的界面。报告确切的命令或交互步骤以及观察到的结果。若无法执行检查，标记为未验证并说明剩余内容；绝不能将验证缺口转化为问题。

9. Review Without Mutating by Default

9. 默认以只读方式评审

Treat a review request as read-only. Do not edit source code unless the user also asks to implement the findings. When implementation is requested, preserve the consolidated report as the change scope and re-run the relevant verification afterward.

将评审请求视为只读操作。除非用户同时要求实现评审结果，否则请勿编辑源代码。当用户要求实现时，保留整合后的报告作为变更范围，并在之后重新运行相关验证。

Common Mistakes

常见错误

Mistake	Fix
Six disconnected domain reports	Consolidate into one ranked findings table
Same issue reported by multiple skills	Assign it to the skill that owns the underlying rule
Finding with no exact location	Cite `path/to/file:line` and the current implementation
Visual claim inferred only from source	Inspect the rendered state or mark it not verified
Unlimited low-impact polish	Respect the mode cap; omit `LOW` findings in `quick`
Silent gaps in coverage	Show which domains and states were actually inspected
No rejected candidates	Include the required considered-but-rejected table
Review silently edits code	Stay read-only unless implementation was requested
“Approve” with pending actionable findings	Use `Needs changes` or `Block`

错误	修复方案
生成六个独立的领域报告	整合为一份按优先级排序的问题表格
同一问题被多个技能重复报告	将问题分配给拥有底层规则的技能
问题未标注确切位置	标注 `path/to/file:line` 并展示当前实现
仅通过源代码推断视觉问题	检查渲染后的状态或标记为未验证
无限制地列出低影响的细节优化	遵守模式的问题数量上限； `quick` 模式下省略 `LOW` 级问题
未明确说明覆盖范围的缺口	展示实际检查的领域和状态
未列出被否决的候选方案	必须包含“已考虑但未采纳”表格
评审时擅自编辑代码	保持只读，除非用户要求实现变更
存在待处理的可操作问题却给出“通过”结论	使用“需修改”或“阻塞”结论

Review Output Format

评审输出格式

Always use the following sections.

始终遵循以下章节结构。

Scope and Coverage

范围与覆盖情况

State the mode, exact scope, stack and styling conventions, and any review boundary. Then show coverage:

Domain	Evidence inspected	Result
Accessibility	Files, components, states, or checks	Findings count or `Clear`

Include all six domains.

Clear

means inspected with no actionable finding;

Not reviewed

must explain why.

说明评审模式、确切范围、技术栈和样式约定，以及任何评审边界。然后展示覆盖情况：

领域	检查的证据	结果
Accessibility	文件、组件、状态或检查项	问题数量或 `无问题`

需包含所有六个领域。

无问题

表示已检查且无可操作问题；

未评审

必须说明原因。

Findings

问题列表

Use one table ordered by severity, then reach and leverage:

#	Severity	Domain	Location	Before	After	Why
1	HIGH	Accessibility	`src/Dialog.tsx:42`	`<button><XIcon /></button>`	Add `aria-label="Close"` and hide the icon from the accessibility tree	The icon-only control has no accessible name

Each row is one root cause. The Domain value is the owning skill without the

better-

prefix. Respect the mode's finding cap. If there are no findings, omit the table and state "No actionable interface findings."

使用一个按严重程度排序，再按影响范围和修复价值排序的表格：

#	严重程度	领域	位置	当前实现	建议修改	原因
1	HIGH	Accessibility	`src/Dialog.tsx:42`	`<button><XIcon /></button>`	添加 `aria-label="Close"` 并将图标从可访问性树中隐藏	仅含图标的控件无可用的无障碍名称

每一行对应一个根本原因。领域值为去掉

better-

前缀的技能名称。遵守模式的问题数量上限。若无问题，省略此表格并说明“无可操作的界面问题”。

Considered but Rejected

已考虑但未采纳的方案

Include 1–3 candidates in

quick

mode and 2–5 in

full

mode:

Location	Candidate	Rejected because
`src/Card.tsx:28`	Increase the shadow	Existing depth matches the shared surface token; changing one card would reduce consistency

These are real candidates inspected during the review, not invented filler. If the scope genuinely contains fewer borderline candidates, include the ones that exist and say so.

quick

模式下需包含1–3个候选方案，

full

模式下需包含2–5个：

位置	候选方案	未采纳原因
`src/Card.tsx:28`	增加阴影	现有深度与共享的表面令牌匹配；修改单个卡片会降低一致性

这些必须是评审过程中实际考虑过的候选方案，而非虚构内容。若范围内确实没有那么多边缘候选方案，列出已有的即可并说明情况。

Verification

验证情况

List each check or interaction, the exact command or steps, and the observed result. Separate checks that passed from checks marked Not verified.

列出每项检查或交互、确切的命令或步骤，以及观察到的结果。区分已通过的检查和标记为未验证的检查。

Verdict

评审结论

End with exactly one:

```
Block
```
— one or more
```
HIGH
```
findings remain.
```
Needs changes
```
— only
```
MEDIUM
```
or
```
LOW
```
findings remain.
```
Approve
```
— no actionable findings remain and the claimed coverage was verified.

最终仅选择以下结论之一：

```
阻塞
```
— 存在一个或多个
```
HIGH
```
级问题。
```
需修改
```
— 仅存在
```
MEDIUM
```
或
```
LOW
```
级问题。
```
通过
```
— 无可操作问题，且声明的覆盖范围已验证。