关于 mobile-design-review
mobile-design-review 是用于审查移动应用设计、评分并维护设计基线的技能。默认只生成报告，不修改应用文件；只有用户要求时才进入修复流程。
主要功能
- 01静态与实时设计审查
- 02十类评估标准与评分
- 03基于基线比较回归
- 04可选且设有上限的修复流程
适用场景
- 01发布前审查移动应用
- 02将新一轮审查与基线比较
- 03检查指定屏幕的设计问题
- 04按要求修复并跟踪风险
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/mobile-design-review确认已加载。
详细介绍
mobile-design-review：审查、评分、基线
默认仅报告。--fix（或用户要求修复发现的问题）才会启用修复循环。绝不在未告知的情况下同时执行两者。
方法见 ../_shared/references/review-rubric.md（检查轮次、叙述、Trunk Test、发现项格式、十个类别、评分计算、基线文件）和 ../_shared/references/tells.md（grep 检查清单与问题特征目录）。修复建议引用 ../_shared/references/redesign-protocol.md（杠杆顺序）以及 ../mobile-taste/SKILL.md 中的章节。开始前请阅读这四个文件。
流程
- 识别技术栈。 检查
package.json/app.json/ 主题文件 /MOBILE-DESIGN.md/design-baseline.json。如果存在基线，本次运行就是回归运行——报告应优先呈现变化。 - 确定范围。 默认检查整个应用；如果用户限定了范围，则检查指定的屏幕/流程。列出将覆盖的屏幕（根据路由树），明确覆盖范围。
- 静态检查（始终执行）：先运行
tells.md中的 grep 代码块，再按十个评分类别检查代码。对每项命中进行分类处理。 - 实时检查（条件允许时）：按以下顺序检查：模拟器 → Expo Web 手机视口 → 用户提供的截图。对每个屏幕：截图、讲述第一印象、执行 Trunk Test、检查触控目标；条件允许时检查深色模式和大字体。如果无法访问任何一种环境，请说明并继续仅进行静态检查。
- 发现项。 按照
review-rubric.md中的格式：FINDING-NNN [impact | category]、证据、对应时的问题特征编号、具体修复方案。 - 评分。 按机械式字母评分规则计算 Design Score 和 AI Slop Score。用表格列出各类别的字母评分。不得向上取整。
- 基线。 写入/更新
design-baseline.json。回归运行时，变化表（类别变更、新增、已解决）必须放在最前面。 - 报告。 包含叙述、Trunk Test 结果、按影响程度排列的发现项、评分、明确的未验证项目列表（“无法访问设备：键盘、启动页、滚动性能、字体缩放、沉浸式边缘均未验证”），以及在仅报告模式下，按照
../_shared/references/redesign-protocol.md中的现代化杠杆顺序排列的建议修复顺序。
修复模式（仅限主动选择）
运行 redesign-protocol.md 中的修复循环：每个原子提交修复一个发现项（style(design): FINDING-NNN ...）；如果存在实时检查，则提供修复前/后的截图；复查以完成闭环；执行风险管控（风险超过 20% 时停止，最多修复 20 项）；在基线中将发现项标记为 fixed。限制：
- 绝不更改导航结构、路由名称、深度链接、标签顺序、令牌名称或表单字段语义——这些属于 redesign-skill 的范畴，须经批准后才能处理。
- 先处理高影响发现项，再处理中等影响项；只有用户要求润色时才进行细节打磨。
- 触及风险管控阈值后停止也属于成功状态：报告已修复项、剩余项和风险计算结果。
对本技能有约束力的规则
- 仅报告意味着绝不修改应用文件。唯一获准写入的是
design-baseline.json（本次审查自身的产物）；如果用户要求零写入，则连该文件也不写入，而是在报告中直接内嵌 JSON。 - 每项评分都必须遵循计算规则；每个被排除的 grep 命中都必须说明一行理由。
- 如果项目声明了设计约定——例如
MOBILE-DESIGN.md或任何同等的已提交设计文档——发现项还必须指出与这些约定的偏离（DRIFT），例如声明的强调色使用不一致、导航描述与实际代码不符。请注明所依据的文档。
评论
支持 Markdown