设计评审（Refactoring UI）
知识存储在 references/ 目录下。切勿一次性加载所有内容。请按以下链条操作：
SKILL.md → INDEX.md → 仅加载所需的文件。
1. 分类请求
| 任务类型 | 信号 | 加载内容 |
|---|---|---|
| 组件修复 | "审查这些卡片 / 这个表单 / 导航栏" | references/components/INDEX.md → 1–2 个 components/<name>.md |
| 屏幕审计 | "审查这个页面 / 屏幕 / 应用" | references/principles/INDEX.md → hierarchy.md, layout-spacing.md, typography.md, color.md；仅当相关时添加 depth.md, images.md, finishing.md |
| 重新设计 | "重新设计 / 提出更好的版本" | 屏幕审计集 + personality.md + systems.md (+ process.md) |
| 美化 | "让它看起来更精致 / 收尾工作" | finishing.md, depth.md, images.md |
| 全新设计 | "从头设计一个…" | process.md, personality.md, systems.md，然后根据需要的主题文件 |
同时识别屏幕上出现的组件（参见 components/INDEX.md 中的描述）；对于屏幕审计，打开1–2个主要组件的文件。
2. 捕获界面
按可用性顺序使用以下方法：
- 浏览器工具（Chrome中的Claude、内置浏览器、Playwright MCP）：打开页面，截取屏幕截图，然后使用工具的 JavaScript 执行功能运行
scripts/measure_styles.js。要将范围限定到某个区域，先运行window.__DR_ROOT = '<css selector>'。 - Shell + Playwright（Claude Code）：
python3 scripts/capture.py <url|file> [--selector ".card"] [--out dir]→ 屏幕截图、灰度截图、measurements.json。 - 仅屏幕截图：仅进行视觉检查；说明测量数据不可用。
- 仅代码：阅读 CSS/标记并手动计算相同的信号。
始终执行灰度测试（PRO-03）：查看去饱和版本（capture.py 会生成一个灰度版本；在浏览器工具中应用 document.documentElement.style.filter='grayscale(1)'，截图，然后移除滤镜）。
3. 分析
- 将每个发现映射到一个原则 ID。使用测量数据作为证据（
measurements.json的键引用了measure_styles.js注释中的 ID）。 - 按照以下影响顺序进行检查：层次 → 间距/布局 → 排版 → 颜色/对比度 → 深度 → 图像 → 收尾。
- 测量数据是提示而非最终判断：在报告之前，请对照屏幕截图逐一确认。
- 除非要求更改，否则尊重现有的品牌/个性（PER-*）。对于重新设计，请先说明目标个性。
[process]原则指导重新设计；不要在审计中将其报告为缺陷。
4. 交付
A. 发现 — 按影响排序，最多约10条，每条格式为：
[ID] 问题 — 证据（测量值或可见内容）→ 修复方案（来自书籍比例的具体值）
B. 修正后的设计 — 除非用户只需要评审意见：
- 将屏幕/组件重建为一个自包含的 HTML/CSS 页面，应用修复方案，并使用原理文件中的比例（间距 4/8/12/16/24/32/48/64…，字体 12/14/16/18/20/24/30/36/48…，5级阴影，100–900 颜色深浅）。尽可能并排显示前后对比（截图）。
- 或者，如果用户想要改代码，则给出 CSS/标记补丁。
C. 系统总结（重新设计） — 使用的字体比例、间距比例、调色板（灰度 + 主色 + 强调色，采用 HSL 格式）和阴影，以便团队采用。
规则
- 引用 ID；不得凭空发明超出参考资料范围的原则。如果某方面未被覆盖，请说明它不在本书范围内。
- 优先选择少数、高影响力的更改，而非长列表。
- 不要复制本书的文字；参考资料是经过释义的摘要。
维护
原则文件是真理之源。编辑它们后，重新生成索引和组件文件：
python3 tools/build_indexes.py skills/design-review（脚本位于源代码仓库的 tools/ 目录中，不在已安装的技能内）。