以 skill 自身的术语
面向任何构建 UI 组件或审查前端代码的人所写的设计工程原则，用于让界面感觉更精致：悬停状态、阴影、边框、字体排印、图标、微交互以及进入/退出动画。
它包含十九条带有硬性默认值的编号核心原则——同心圆边框半径、光学对齐、分层阴影（而非伪造层级的边框）、可中断的 CSS 过渡、约 100ms 的交错动画、抗锯齿文本、等宽数字、纯黑或纯白的图片轮廓、按压时的 scale(0.96)、44×44px 的点击区域，以及与文本粗细匹配的图标描边。两种审查模式——快速与完整——会生成一个按原则分组、上限为 5 或 15 条发现的 Severity/Location/Before/After/Why 表格，并以 Block、Needs changes 或 Approve 结尾。
它产出什么
- 一份预先说明检查范围的审查报告，绝不暗示未检查的部分已被覆盖。
- 按原则分组的发现，列在一个 Severity、Location、Before、After、Why 表格中，列出所有已做出或建议的更改，而非其中一部分。
- 一个“已考虑但被否决”的表格，快速模式下包含 1–3 个真实候选方案，完整模式下包含 2–5 个，每个都附有被否决的原因。
- 一个验证部分，列出实际运行的命令或交互及其观察结果，随后给出结论。
工作方式
- 01用项目自身的样式系统表达修复方案
在提出或编写任何修复方案之前，先弄清项目已有的样式方式，并用该体系来表述改动——Tailwind 项目用 Tailwind，CSS 项目用纯 CSS，或遵循既有的 CSS-in-JS 方案。
- 02放慢界面速度
审查时，在浏览器的 Animations 面板中以 10% 速度回放动效，因为在 10% 速度下看起来不对的地方，正是全速下微妙出错的地方。
- 03默认采用完整模式
未指定审查模式时默认使用完整模式；快速模式必须明确要求才会启用。
- 04以固定表格格式写下发现
按原则将发现分组，用带 Severity、Location、Before、After 和 Why 列的 markdown 表格呈现；Location 引用 path/to/file:line。
- 05覆盖全部五个类别
范围表必须涵盖 Quick Reference 中全部五个类别，未检查的部分绝不能被暗示为已审查。
- 06以验证与结论收尾
存在 HIGH 级发现时结论为 Block；仅存在 MEDIUM 或 LOW 级发现时为 Needs changes；没有任何可操作项时才为 Approve。