design-parity-review 用于证明某个 Compose UI 的 pull request 与其目标设计达成一致（design → code 方向）。它在 UI PR 上会解析与变更组件匹配的设计参考、通过 compose-preview 渲染新代码（候选），再将候选与参考稿做视觉、语义与 token 层面的 diff，最终在 PR 中发布结论，例如「实现了 Figma Button/Primary；padding 12dp 而规格为 16dp；暗色主题对比度未通过 AA」。候选侧使用上游 compose-preview 渲染器，该技能负责参考侧以及决定设计↔代码对应关系的对应层。
使用方向需先确定：本技能为 design → code；若要把组件系统发布为 Figma 贴纸稿，属于 code → design，应使用 compose-design-catalog → figma-catalog-import；若只比较渲染 UI 与上次提交的差异、不涉及设计，应使用 compose-preview-review。双向往返受支持，但哪一侧为准是提交的决策而非每次运行的选择。
设置顺序为：1）在 .design-parity.json 中确定方向，direction 可取 code-led（代码为准，发现问题但不阻塞）、design-led（设计为准，不一致则阻塞）或 auto（由 @design-parity/policy 按仓库成熟度确定性解析）；2）用 design-map.json 建立代码到设计的映射，解析顺序为 Code Connect（仅 Figma）→ 已提交的 design-map.json → 名称约定（低置信度标记），一个代码句柄可按 state/theme 绑定多个设计节点，也可用 npx design-parity reverse figma:AbCdEf/1:42 反查；若仓库无已提交映射，不会在运行时猜测，而是提示使用交互式 bootstrap，且不会阻塞；带 @CatalogComponent(reference = …) 注解的 Compose 目录可从注解派生映射，无需 bootstrap；3）选择参考来源：claude-design 无需认证、离线确定；figma 需 FIGMA_TOKEN，是唯一具备自动对应关系的来源，但受速率限制；stitch 需认证及无头 Chrome，ref 格式为 stitch:<projectId>/<screenId>；bundle 为已提交的 PNG + manifest.json；4）渲染候选，建议在代表实际发布 UI 的目标上渲染，主题按预览主题提示、Android uiMode、预览 id 尾部 _Dark/_Light/Night token 的优先级推导，需确保 bundle 携带语义 blob，否则无障碍、对比度与 token 检查会静默退化为仅视觉/结构检查；平台专属 UI 需在 Android 渲染或上提到 commonMain；5）先接好参考缓存，再接入运行，否则每次提交都会实时拉取参考并触发限流；6）通过 .github/workflows/design-parity.yml 接入运行。
结论按重要程度排序：无障碍与国际化优先，其次 token，最后像素。推送到开发分支时会发布可浏览产物到常驻的 design-parity/<dev-branch> 分支，包括 index.html、各组件的 report.html 三联图、verdict.json 以及 tokens/design-system.tokens.json。历史自动累积且为线性链快进推送，未变更屏幕的运行不产生提交噪音。该工具维护于 github.com/yschimke/skills 的 skills/design-parity-review/，从 yschimke/design-parity 发布并在 npm 上以 design-parity 提供，可用 npx design-parity … 运行，无需 checkout。缺少事实的收费信息暂未提供。