design-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Design review

设计评审

A written critique of rendered UI. It does not fix the design or rewrite copy. Criteria are in
references/review-criteria.md
, and finding the design, evidence and probes in
references/sources.md
.
对已渲染UI的书面评审。本技能不修改设计或重写文案。评审标准见
references/review-criteria.md
,设计查找、证据与探测方法见
references/sources.md
。

Start from whatever the ask gives

从用户请求的内容入手

"Check this screen before I ship" is enough. Defaults:
  • The design: a scope the caller names, else the branch's changed screens, else top routes (
    references/sources.md
    ).
  • The purpose: inferred and marked assumed at the top of the record.
  • Viewports: the widths of supplied images, else the narrowest and widest the app supports, default 390 and 1280 px. "On mobile" or a named device class means the phone width only (
    references/sources.md
    ).
“上线前帮我检查这个界面”就足够了。默认值:
  • 评审范围:调用者指定的范围,若未指定则为当前分支变更的界面,仍未指定则为顶层路由(
    references/sources.md
    )。
  • 评审目的:自动推断,并在记录顶部标记为“假设”。
  • 视口:使用提供的图片宽度,若未提供则为应用支持的最窄和最宽宽度,默认390px和1280px。“移动端”或指定设备类别的请求仅使用手机宽度(
    references/sources.md
    )。

When a coordinator calls it

协调者调用时的处理规则

Take the captures, criteria and purpose as given and run to the end, recording any gap the solo path would ask about. With captures only, the scan and probes read
not run: captures only
, which counts as a reason. Start the report with a status line,
Status: complete (Blocking n, Should fix n, Note n)
,
Status: complete (partial: <what was not reviewed>)
or
Status: stopped: <condition>
, then
Commit: none
, then the answer and ship lines. Return the report, or the stop shape, as text and write no report file.
直接使用提供的截图、评审标准和目的,完整执行评审流程,记录独立执行模式下会询问的所有信息缺口。若仅提供截图,则扫描和探测步骤显示为
not run: captures only
,该状态可作为未执行的理由。 报告以状态行开头,格式为
Status: complete (Blocking n, Should fix n, Note n)
、
Status: complete (partial: <what was not reviewed>)
或
Status: stopped: <condition>
,随后是
Commit: none
,再之后是答复和上线结论行。 以文本形式返回报告(或终止说明),不写入报告文件。

Steps

步骤

  1. Find the design. Capture each screen at each viewport and run the accessibility scan there (
    references/sources.md
    ). Done when the record lists the source, tool, viewports, scan and today's date.
  2. Probe dialogs and forms per
    references/sources.md
    , on a local build only. Done when each probe has a measured result or a reason it did not run.
  3. Fix the purpose. Stop if the purpose is unreadable or contradicts the screen, two versions arrived with nothing marking the current one, or the criteria contradict AGENTS.md or CLAUDE.md with no rule on which wins.
  4. Walk the criteria. Done when each criterion is checked at each viewport.
  5. Sort. Merge repeats into one finding with a count. When one finding's recovery lands in another, say so in both and rank them together. Taste goes to Left out. A deliberate departure, or a problem no criterion covers, goes to For a person to decide.
  6. Sort accessibility observations. Contrast, target size and keyboard problems are ranked. A tree change follows
    ../build-design-system/references/traps.md
    (Adds-only accessibility changes), a path relative to this skill's folder.
  7. Rank by the criteria file's severities. Order each group by how many places it hits.
  8. Walk the edge cases, marking each shown or not shown, plus the States rows of each spec for a component on the screen, checked against the screen (
    references/sources.md
    , Component specs).
  9. Write the verdict and summary last. Done when the readiness list below holds.
  1. 确定评审设计。 在每个视口下截取每个界面的截图,并运行可访问性扫描(
    references/sources.md
    )。当记录中列出了来源、工具、视口、扫描结果和当前日期时,本步骤完成。
  2. 探测对话框与表单 依据
    references/sources.md
    执行,仅在本地构建版本上运行。当每个探测项都有可衡量的结果或未执行的理由时,本步骤完成。
  3. 确认评审目的。 若目的无法理解、与界面内容矛盾,或收到两个版本且未标记当前版本,或评审标准与AGENTS.md或CLAUDE.md冲突且无优先级规则,则终止评审。
  4. 逐项核对标准。 当所有标准在每个视口下都完成检查时,本步骤完成。
  5. 分类整理。 将重复的问题合并为一条,并标注出现次数。若某个问题的修复方案会涉及另一个问题,则在两条问题中都说明并合并排序。主观审美问题归入“未纳入”类别。刻意的设计偏离,或无对应评审标准的问题,归入“待人工决策”类别。
  6. 整理可访问性观察结果。 对比度、可点击区域大小和键盘操作问题会进行优先级排序。页面结构树变更需遵循
    ../build-design-system/references/traps.md
    (仅新增可访问性变更相关),该路径为相对于本技能文件夹的相对路径。
  7. 优先级排序 依据评审标准文件中的严重等级划分。每个分组内按问题影响的位置数量排序。
  8. 检查边界场景 标记每个边界场景是否已覆盖,同时对照界面检查页面上每个组件规格的状态行(
    references/sources.md
    ,组件规格)。
  9. 最后撰写结论与摘要。 当满足下方的就绪条件列表时,本步骤完成。

Output

输出

Any Blocking finding makes the verdict
no
, and an inferred one
no, pending <the one check that settles it>
. Should fix alone makes it
yes, with fixes
, and only Notes
yes
. The first line answers the ask in plain words, with no criterion numbers or skill names, and "Not yet" pairs only with
no
. The ship line follows with the same verdict, why in one clause, and the count of unranked accessibility questions for a person. A partial run's verdict covers only what was reviewed. Example:
Ready to ship: no. Enter in Email cancels the invite (Blocking 1, Should fix 2, 3 accessibility questions for a person).
Then six parts.
  1. Review record. Source, tool, viewports, date, criteria file, first pass or follow-up, the purpose marked given or assumed, every assumption, and every gap. Each n/a criterion gives its reason ("8. No destructive action on this screen").
  2. Summary. What the screen asks, what works, and what most needs attention.
  3. Findings by severity group. Each gives what was seen, where (screen and region, or the element by role and name with its ref or selector and capture, as in
    button 'Save changes' @e34 (settings-1280.png)
    ), the viewport, the criterion by number and name, why it matters for this task, and the evidence label (
    references/sources.md
    , What counts as evidence), and any matching
    trap/
    or
    rule/
    ID.
  4. Edge cases not shown. One line each.
  5. For a person to decide. Semantics-changing accessibility fixes, product decisions a fix needs, and problems no criterion covers, each tied to a finding or location.
  6. Left out. Preferences dropped, each with the reason.
An empty group says "None", and a clean screen's Notes stay Notes.
The report is ready when:
  • Every finding has a criterion, a findable location, evidence, and only the viewports where it shows.
  • The first line, ship line and summary give one verdict that matches the findings.
  • Every probe has a result or a reason, and the scan ran at each viewport or reads
    not run: captures only
    .
  • Every claim that something works or is fixed names its command or capture from this session.
Run directly, save the report to
.design-review/<date>-<flow>.md
with captures beside it. The chat reply opens with the answer and ship lines, gives each command run with its exit code, lists up to three items for a person with defaults, and ends with
Next:
and one prompt to paste. That prompt covers every Blocking and shown-versus-sent finding as "Fix X so that <check>", such as "Fix Enter in Email so that it sends 1 POST". Each Next check must fail on the current build.
A stopped run returns only what stopped it, a one-line guess at what each screen does, and the shortest reply that unblocks it.
若存在任何阻塞性(Blocking)问题,结论为
no
;若为推断的阻塞问题,则结论为
no, pending <the one check that settles it>
。仅存在应修复(Should fix)问题时结论为
yes, with fixes
;仅存在注意事项(Notes)时结论为
yes
。 报告第一行用平实的语言答复用户请求,不包含标准编号或技能名称,且“Not yet”仅与
no
搭配使用。随后是上线结论行,包含相同的结论、一句话理由,以及待人工决策的未排序可访问性问题数量。部分执行的评审结论仅覆盖已评审的内容。示例:
Ready to ship: no. Enter in Email cancels the invite (Blocking 1, Should fix 2, 3 accessibility questions for a person).
报告包含六个部分。
  1. 评审记录。 包含来源、工具、视口、日期、评审标准文件、首次评审或跟进评审、标记为“给定”或“假设”的评审目的、所有假设,以及所有信息缺口。每个不适用(n/a)的标准都需说明理由(例如“8. 本界面无破坏性操作”)。
  2. 摘要。 说明界面的用途、运行正常的部分,以及最需要关注的问题。
  3. 问题列表 按严重等级分组。每条问题包含:问题描述、位置(界面和区域,或元素的角色与名称,以及其引用、选择器和截图,例如
    button 'Save changes' @e34 (settings-1280.png)
    )、视口、对应标准的编号与名称、该问题对当前任务的影响,以及证据标签(
    references/sources.md
    ,证据判定标准),还有匹配的
    trap/
    或
    rule/
    ID。
  4. 未覆盖的边界场景。 每条占一行。
  5. 待人工决策。 包含会改变语义的可访问性修复、修复所需的产品决策,以及无对应标准的问题,每条都关联到具体问题或位置。
  6. 未纳入项。 被排除的主观偏好类问题,每条附理由。
若某分组无内容,显示为“None”;即使界面完全符合标准,注意事项(Notes)分组仍会保留。
报告满足以下条件时即为就绪:
  • 每条问题都有对应标准、可定位的位置、证据,且仅列出问题出现的视口。
  • 第一行、上线结论行和摘要给出的结论一致,且与问题列表匹配。
  • 每个探测项都有结果或未执行理由,扫描已在每个视口下运行,或显示
    not run: captures only
    。
  • 所有关于功能正常或已修复的声明,都需标注本次评审中使用的命令或截图。
直接运行时,报告保存至
.design-review/<date>-<flow>.md
,截图存放在同目录下。聊天回复首先给出答复发起行和上线结论行,然后列出每个执行的命令及其退出码,最多列出3项待人工处理的默认事项,最后以
Next:
和一个可粘贴的提示结束。该提示以“Fix X so that <check>”的格式覆盖所有阻塞性问题以及实际显示与预期不符的问题,例如“Fix Enter in Email so that it sends 1 POST”。每个Next检查项在当前构建版本上必须是失败状态。
若评审终止,仅返回终止原因、每个界面用途的一行猜测,以及解除阻塞的最短回复。

Hard limits

严格限制

  • Every finding rests on a criterion in the file in use, never on taste.
  • Review the render. A description, DOM text or source code only supports a finding.
  • A person rules on semantics-changing accessibility fixes and product decisions, and the finding stays.
  • 所有问题都必须基于当前使用的标准文件中的条款,绝不基于主观审美。
  • 评审对象为渲染后的界面。设计描述、DOM文本或源代码仅作为问题的辅助证据。
  • 会改变语义的可访问性修复和产品决策由人工判定,且原问题保留。