Back to Details

pixel-perfect

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

pixel-perfect

像素级复刻

A skill for reproducing a UI as exactly as possible from a screenshot, image, Figma preview/export, clickable demo, or live website.
The result is not just code. The result is:
  • a measurement-based implementation plan
  • a detailed visual specification
  • the code that implements that specification
  • an iterative validation loop until the rendered result matches the reference closely
This skill is for exact copying, not for inspiration, redesign, cleanup, normalization, or stylistic interpretation.
这是一项可从截图、图片、Figma预览/导出文件、可点击演示或在线网站中尽可能精确复刻UI的技能。
最终产出不只是代码，还包括：
  • 基于测量的实现方案
  • 详细的视觉规格说明
  • 符合该规格的实现代码
  • 迭代验证循环，直到渲染结果与参考素材高度匹配
本技能仅用于精确复制，不用于获取灵感、重新设计、清理、标准化或风格化解读。

When to use this skill

何时使用本技能

Use this skill when the user wants to:
  • copy a design exactly
  • reproduce a screen from a screenshot
  • clone a Figma site or demo accurately
  • match spacing, padding, colors, typography, and layout in detail
  • port a design into another framework without changing the look
Do not use this skill when the user wants:
  • a redesign
  • a design critique
  • a looser "something like this" implementation
  • UX improvements instead of replication
当用户需要以下操作时使用本技能：
  • 精确复制某一设计
  • 从截图还原界面
  • 精准克隆Figma站点或演示
  • 细致匹配间距、内边距、颜色、排版和布局
  • 在不改变外观的情况下将设计迁移到其他框架
当用户需要以下操作时请勿使用本技能：
  • 重新设计
  • 设计评审
  • 宽松的“类似这样”的实现
  • 用户体验优化而非复刻

Prerequisites

前置条件

  • MCP servers:
    • Chrome DevTools MCP (preferred) or Playwright MCP (fallback)
  • Command-line tools: 
    • jq
    • awk
    • ImageMagick: 
      magick
      (v7) or 
      convert
      + 
      compare
      + 
      identify
      (v6)
  • MCP服务器：
    • Chrome DevTools MCP（首选）或Playwright MCP（备选）
  • 命令行工具： 
    • jq
    • awk
    • ImageMagick：
      magick
      （v7版本）或
      convert
      + 
      compare
      + 
      identify
      （v6版本）

How to use this skill

如何使用本技能

Use this skill as a strict execution loop:
  1. measure the reference once and create a concrete specification
  2. implement from that specification
  3. verify against the reference artifacts
  4. modify only the mismatched areas
  5. verify again
Repeat steps 3 to 5 until every required issue is resolved (
fixed
, 
accepted_by_user
, or 
renderer_only_drift
) and the validation gates pass.
按照严格的执行循环使用本技能：
  1. 对参考素材进行一次测量，创建具体的规格说明
  2. 根据该规格进行实现
  3. 对照参考素材验证实现结果
  4. 仅修改不匹配的部分
  5. 再次验证
重复步骤3至5，直到所有必要问题都得到解决（状态为
fixed
、
accepted_by_user
或
renderer_only_drift
）且验证关卡通过。

Core rules

核心规则

  1. The reference is ground truth.
  2. Do not redesign.
  3. Do not simplify.
  4. Do not "improve" the design.
  5. Do not replace measured values with rounded or nicer values unless explicitly asked.
  6. Do not substitute theme defaults for measured colors, font sizes, spacing, radius, or shadows.
  7. If the source is inspectable, measure it.
  8. Always finish with screenshot-based visual validation.
  9. Do not stop at "close enough" if obvious differences remain.
  10. Prefer fidelity over framework convention.
  1. 参考素材是绝对标准。
  2. 不得重新设计。
  3. 不得简化设计。
  4. 不得“优化”设计。
  5. 除非明确要求，不得将测量值替换为取整或更规整的值。
  6. 不得用主题默认值替代测量得到的颜色、字体大小、间距、圆角或阴影。
  7. 若源素材可检查，务必进行测量。
  8. 最终必须进行基于截图的视觉验证。
  9. 若存在明显差异，不得止步于“差不多”。
  10. 优先保证还原度，而非遵循框架惯例。

Normative terms

规范性术语

  • MUST
    and 
    MUST NOT
    are hard requirements.
  • SHOULD
    is a strong default that may be overridden only with explicit justification in the report.
  • MUST
    和
    MUST NOT
    为硬性要求。
  • SHOULD
    为强默认规则，仅在报告中提供明确理由时可被覆盖。

Priority order

优先级顺序

When tradeoffs must be made, prioritize in this order:
  1. overall layout structure
  2. outer margins and section spacing
  3. inner padding and gaps
  4. typography, font size, weight, line height
  5. colors, borders, radius, shadows
  6. asset parity for fonts and icons
  7. icon size and placement
  8. interaction states and minor details
当必须做出权衡时，按以下优先级排序：
  1. 整体布局结构
  2. 外边距和区块间距
  3. 内边距和间隙
  4. 排版、字体大小、字重、行高
  5. 颜色、边框、圆角、阴影
  6. 字体和图标资源一致性
  7. 图标尺寸和位置
  8. 交互状态和细节

Input preference order

输入优先级顺序

Accepted input types in priority order:
  1. Figma inspectable source
  2. live website
  3. clickable demo
  4. image export
  5. screenshot
Rules:
  • use the highest-priority available source as the primary measurement source
  • use lower-priority sources only as supplemental visual confirmation when needed
  • use runtime sources for behavior and state confirmation when those details are not represented in Figma
  • if only one source is provided, use that source
接受的输入类型优先级如下：
  1. 可检查的Figma源素材
  2. 在线网站
  3. 可点击演示
  4. 图片导出文件
  5. 截图
规则：
  • 使用优先级最高的可用源作为主要测量源
  • 仅在需要补充视觉确认时使用优先级较低的源
  • 当Figma中未体现行为和状态细节时，使用运行时源进行确认
  • 若仅提供一个源，则使用该源

Required output

必需输出

This skill must produce four things during execution:
  1. a short execution plan
  2. a detailed measurement-based UI specification
  3. the implementation in code
  4. validation results and remaining mismatches, if any
The agent must not jump straight into coding without first creating the specification.
Use the report heading schema in 
references/report-template.md
.
Use two reporting modes:
  • iteration
    mode during refine loops (compact summary projection, changed/failing items only)
  • final
    mode at completion handoff (full-fidelity report)
Do not enforce fixed token limits. Keep intermediate output concise by using artifact projections instead of repeating full report content.
When the agent believes the task is complete, it MUST provide a final user-verification handoff that includes all of the following:
  1. an explicit statement that it believes the implementation is done
  2. a side-by-side visual comparison showing:
    • one image of the reference/design
    • one image of the actual rendered app
  3. a direct request for user verification that asks whether anything is still missing
  4. an explicit prompt to list missed details if the user does not approve
执行本技能时必须生成以下四项内容：
  1. 简短的执行计划
  2. 基于测量的详细UI规格说明
  3. 代码实现
  4. 验证结果及剩余不匹配项（若有）
代理不得跳过规格说明直接开始编码。
使用
references/report-template.md
中的报告标题模板。
采用两种报告模式：
  • 迭代循环期间使用
    iteration
    模式（简洁的摘要投影，仅展示变更/未通过项）
  • 完成交付时使用
    final
    模式（完整保真度报告）
无需强制限制token数量。通过素材投影而非重复完整报告内容来简化中间输出。
当代理认为任务完成时，必须提供包含以下内容的最终用户验证交付：
  1. 明确声明认为实现已完成
  2. 并排视觉对比图，包含：
    • 参考素材/设计的图片
    • 实际渲染应用的图片
  3. 直接请求用户验证是否仍有遗漏
  4. 明确提示用户若不认可，请列出遗漏的细节

References

参考资料

Use these references for detailed execution guidance:
  • references/report-template.md
  • references/responsive-scope-playbook.md
  • references/measurement-playbook.md
    (index)
  • references/measurement-chrome-devtools.md
  • references/measurement-image.md
  • references/measurement-figma.md
  • references/specification-playbook.md
  • references/validation-playbook.md
以下参考资料提供详细执行指导：
  • references/report-template.md
  • references/responsive-scope-playbook.md
  • references/measurement-playbook.md
    （索引）
  • references/measurement-chrome-devtools.md
  • references/measurement-image.md
  • references/measurement-figma.md
  • references/specification-playbook.md
  • references/validation-playbook.md

Workflow

工作流程

Phase 1, identify source type

阶段1：识别源类型

Determine which of these applies:
  • live inspectable source
  • Figma inspectable source
  • static visual source only
If there is a live inspectable source, use that as the primary measurement source. If there is a Figma inspectable source, use Figma inspect data as the primary measurement source. If there is only an image, use screenshot-based measurement.
Source selection MUST follow the Input preference order. Lower-priority sources SHOULD be used only as supplemental confirmation unless no higher-priority source is available.
确定属于以下哪种类型：
  • 可检查的在线源
  • 可检查的Figma源
  • 仅静态视觉源
若存在可检查的在线源，将其作为主要测量源。 若存在可检查的Figma源，将Figma检查数据作为主要测量源。 若仅提供图片，则使用基于截图的测量方式。
源选择必须遵循输入优先级顺序。 仅在无更高优先级源可用时，才应使用低优先级源作为补充确认。

Phase 2, select responsive validation scope

阶段2：选择响应式验证范围

Select required viewports before implementation starts. Use the deterministic scope and classification rules in 
references/responsive-scope-playbook.md
.
Minimum requirements:
  • if the user provides explicit viewports or devices, use exactly those
  • otherwise classify source and choose the default viewport set from the playbook
  • source classification, selected viewport set, and selection reason MUST be recorded in the plan
  • validation MUST pass at every required viewport in the selected set
  • any deviation from defaults MUST be explicitly justified in the report
在实现开始前选定所需视口。 使用
references/responsive-scope-playbook.md
中的确定性范围和分类规则。
最低要求：
  • 若用户提供明确的视口或设备，严格使用指定内容
  • 否则对源进行分类，并从手册中选择默认视口集合
  • 必须在计划中记录源分类、选定的视口集合及选择理由
  • 选定集合中的每个必需视口都必须通过验证
  • 任何偏离默认值的情况都必须在报告中明确说明理由

Phase 3, inspect and measure

阶段3：检查与测量

Mode A, live inspectable source

模式A：可检查的在线源

Use browser tooling such as Chrome DevTools MCP to inspect the rendered UI directly. Use the exact measurement sequence in 
references/measurement-chrome-devtools.md
.
Measure and record:
  • viewport size
  • page width and visible content width
  • safe area or browser insets if relevant
  • bounding boxes of key elements
  • x and y positions relative to parent and viewport
  • width and height of sections and controls
  • padding on all sides
  • margins on all sides
  • layout gaps between siblings
  • computed font family
  • computed font size
  • computed font weight
  • computed line height
  • letter spacing if relevant
  • text color
  • background color
  • gradients
  • border width
  • border color
  • border radius
  • box shadow
  • opacity if used
  • icon size
  • alignment rules
  • scroll behavior
  • sticky or fixed positioning, if present
Also capture screenshots of:
  • full viewport
  • each major section
  • each area with dense visual detail
Do not eyeball values from the screenshot first if the DOM can be inspected. Measure first.
使用Chrome DevTools MCP等浏览器工具直接检查渲染后的UI。 遵循
references/measurement-chrome-devtools.md
中的精确测量流程。
测量并记录：
  • 视口尺寸
  • 页面宽度和可见内容宽度
  • 安全区域或浏览器内边距（若相关）
  • 关键元素的边界框
  • 相对于父元素和视口的x、y坐标
  • 区块和控件的宽度与高度
  • 各边的内边距
  • 各边的外边距
  • 同级元素间的布局间隙
  • 计算后的字体族
  • 计算后的字体大小
  • 计算后的字重
  • 计算后的行高
  • 字母间距（若相关）
  • 文本颜色
  • 背景颜色
  • 渐变
  • 边框宽度
  • 边框颜色
  • 边框圆角
  • 盒阴影
  • 透明度（若使用）
  • 图标尺寸
  • 对齐规则
  • 滚动行为
  • 粘性或固定定位（若存在）
同时捕获以下截图：
  • 完整视口
  • 每个主要区块
  • 每个包含密集视觉细节的区域
若可检查DOM，请勿先通过截图目测取值。务必先测量。

Mode B, screenshot or image only

模式B：仅截图或图片

When the design is only available as an image, infer structure and measure visually. Use the screenshot-only procedure in 
references/measurement-image.md
.
Determine:
  • target viewport size, or estimate it
  • main layout containers
  • relative spacing between sections
  • padding inside cards and containers
  • text hierarchy
  • likely font size relationships
  • approximate border radius
  • approximate icon sizes
  • color samples from pixels
  • gradient stops when visible
  • alignment pattern and grid rhythm
Use repeated screenshot comparison during implementation to refine uncertain values.
当设计仅以图片形式提供时，推断结构并进行视觉测量。 遵循
references/measurement-image.md
中的仅截图流程。
确定：
  • 目标视口尺寸，或进行估算
  • 主要布局容器
  • 区块间的相对间距
  • 卡片和容器内的内边距
  • 文本层级
  • 可能的字体大小关系
  • 近似边框圆角
  • 近似图标尺寸
  • 像素取色的颜色样本
  • 可见时的渐变断点
  • 对齐模式和网格节奏
在实现过程中使用重复截图对比来优化不确定的值。

Mode C, Figma source

模式C：Figma源

When the source is a Figma preview or file with inspect access, measure from Figma inspect data. Use the Figma procedure in 
references/measurement-figma.md
.
Measure from inspect values first, then use exported or captured frame images for visual confirmation.
当源为Figma预览或具有检查权限的文件时，从Figma检查数据中进行测量。 遵循
references/measurement-figma.md
中的Figma流程。
优先从检查值中测量，然后使用导出或捕获的帧图片进行视觉确认。

Phase 4, write the execution plan

阶段4：编写执行计划

Before writing the detailed specification, write a concise execution plan.
This plan MUST include:
  • source type
  • measurement approach
  • implementation target
  • validation approach
  • known risks or uncertainties
Example:
Source: clickable demo
Measurement: Chrome DevTools MCP DOM inspection plus screenshots
Target: React Native screen on iPhone-sized viewport
Validation: simulator screenshots matched against reference
Risk: native font rendering may differ slightly from browser rendering
Keep the plan short. It is an execution plan, not the full specification.
在编写详细规格说明前，先编写简洁的执行计划。
计划必须包含：
  • 源类型
  • 测量方法
  • 实现目标
  • 验证方法
  • 已知风险或不确定性
示例：
源：可点击演示
测量方式：Chrome DevTools MCP DOM检查 + 截图
目标：iPhone尺寸视口下的React Native界面
验证方式：模拟器截图与参考素材匹配
风险：原生字体渲染可能与浏览器渲染略有差异
计划需简短，仅为执行计划，而非完整规格说明。

Phase 5, write the detailed implementation specification

阶段5：编写详细的实现规格说明

Create a measurement-based UI spec before coding.
The specification must be concrete enough that another engineer could implement the screen without seeing the original reference. Use the field-level schema and quality checks in 
references/specification-playbook.md
.
Phase 5 concept:
  • produce a complete, measurement-driven implementation contract before coding
Required sections:
  1. Screen metadata
    : defines target environment and global layout behavior.
  2. Component hierarchy
    : defines structural tree and naming used across implementation and validation.
  3. Section-by-section measurements
    : defines geometry, spacing, alignment, and surface styling per major section.
  4. Typography spec
    : defines exact text rendering rules for key text elements.
  5. Color palette
    : defines concrete color values and gradients used by the screen.
  6. Border and radius spec
    : defines borders, corner radii, and divider treatments.
  7. Iconography spec
    : defines icon asset, size, placement, and style details.
  8. Asset parity + user decisions
    : records font/icon availability and user-approved fallback decisions.
  9. Interaction and state notes
    : defines visible state-dependent styling/layout behavior.
  10. Platform translation notes
    : documents renderer translation constraints without redesign.
For required fields and example outputs for each section, use 
references/specification-playbook.md
. All 10 required specification sections MUST be present before implementation starts.
在编码前创建基于测量的UI规格说明。
规格说明必须足够具体，确保其他工程师无需查看原始参考素材即可实现界面。 使用
references/specification-playbook.md
中的字段级模板和质量检查标准。
阶段5核心：
  • 在编码前生成完整的、基于测量的实现约定
必需章节：
  1. 界面元数据
    ：定义目标环境和全局布局行为。
  2. 组件层级
    ：定义实现和验证中使用的结构树及命名规则。
  3. 逐区块测量
    ：定义每个主要区块的几何尺寸、间距、对齐方式和表面样式。
  4. 排版规格
    ：定义关键文本元素的精确文本渲染规则。
  5. 调色板
    ：定义界面使用的具体颜色值和渐变。
  6. 边框与圆角规格
    ：定义边框、圆角和分隔线样式。
  7. 图标规格
    ：定义图标资源、尺寸、位置和样式细节。
  8. 资源一致性 + 用户决策
    ：记录字体/图标可用性及用户批准的备选方案决策。
  9. 交互与状态说明
    ：定义可见的状态相关样式/布局行为。
  10. 平台适配说明
    ：记录渲染器适配约束，不得重新设计。
各章节的必需字段和示例输出请参考
references/specification-playbook.md
。 开始实现前必须包含全部10个必需的规格章节。

Phase 6, acceptance contract (mandatory before implementation)

阶段6：验收约定（实现前必填）

Before implementation starts, the report MUST include an acceptance contract with:
  • Must-match list
    : annotated design decisions that are non-negotiable
  • Ignore list
    : explicitly allowed mismatches
  • Portable-allowed drift
    : renderer-only drift allowances
Rules:
  • implementation MUST NOT start before this contract is recorded
  • if user-marked comparison screenshots are provided, those annotations MUST be reflected in the 
    Must-match list
  • if the screen is data-driven, copy/content mismatches SHOULD be excluded unless they affect layout, spacing, overflow, or wrapping
  • all exclusions MUST be explicitly listed in the 
    Ignore list
开始实现前，报告必须包含验收约定，内容包括：
  • 必须匹配列表
    ：标注不可协商的设计决策
  • 忽略列表
    ：明确允许的不匹配项
  • 可移植允许偏差
    ：仅渲染器层面的偏差许可
规则：
  • 必须记录该约定后才能开始实现
  • 若提供用户标记的对比截图，必须将标注反映在
    必须匹配列表
    中
  • 若界面为数据驱动，除非影响布局、间距、溢出或换行，否则应排除内容不匹配项
  • 所有排除项必须明确列在
    忽略列表
    中

Phase 7, implement from the specification

阶段7：根据规格实现

Write code using the specification as the source of truth.
Rules:
  • implement one section at a time
  • use explicit values
  • avoid framework defaults when they change the appearance
  • do not normalize arbitrary measured values into a spacing scale
  • do not replace actual colors with nearby theme colors
  • do not change font sizes to "more standard" values
  • do not make buttons more balanced or modern
  • do not remove or add detail
  • do not auto-select fallback fonts or icon packs when exact assets are missing
  • implement fallback assets only after explicit user approval is recorded in the specification
  • if the reference uses a recognizably different icon family, you MUST either adopt that icon family or obtain explicit user approval before substantial implementation
If the source uses odd values such as 23px or 18px, keep them.
以规格说明为唯一依据编写代码。
规则：
  • 逐区块实现
  • 使用明确值
  • 若框架默认值会改变外观，避免使用
  • 不得将任意测量值标准化为间距刻度
  • 不得用相近的主题颜色替代实际测量颜色
  • 不得将字体大小改为“更标准”的值
  • 不得使按钮更均衡或现代化
  • 不得增减细节
  • 当精确资源缺失时，不得自动选择备选字体或图标包
  • 仅在规格说明中记录了用户明确批准后，才实现备选资源
  • 若参考素材使用了辨识度较高的不同图标库，必须采用该图标库，或在大量实现前获得用户明确批准
若源素材使用了非规整值（如23px或18px），请保留该值。

Phase 8, run and capture

阶段8：运行与捕获

Run the implementation in the correct target environment.
Use the environment setup defined in the execution plan. Do not switch target environment during validation.
Run checklist:
  • confirm the target type from the plan (
    web
    , 
    react-native
    , or other declared target)
  • start the target in a stable run mode suitable for screenshot capture
  • ensure target fonts and icon assets match the approved asset parity decision
  • disable animations/transitions before capture when possible to reduce frame variance
  • set each required viewport exactly as declared in the plan
  • capture all required screenshots for each viewport
For each required viewport in the selected viewport set, capture screenshots of:
  • the full screen
  • each major section
  • any area that visually differs from the reference
Use the exact viewport size declared in the plan for each pass. Viewport sizes MUST match the plan exactly. Required screenshots for each viewport MUST be captured.
Artifact output requirements:
  • for each viewport, save capture artifacts and validation input files to disk
  • for each viewport, run 
    ./scripts/validate-visual.sh
    and save JSON output (for example 
    validation/<viewport>.json
    )
  • treat validator JSON artifacts as the numeric source of truth
在正确的目标环境中运行实现结果。
使用执行计划中定义的环境设置。验证期间不得切换目标环境。
运行检查清单：
  • 确认计划中的目标类型（
    web
    、
    react-native
    或其他声明的目标）
  • 以适合截图捕获的稳定运行模式启动目标
  • 确保目标字体和图标资源与批准的资源一致性决策匹配
  • 可能时在捕获前禁用动画/过渡，以减少帧差异
  • 严格按照计划中声明的尺寸设置每个必需视口
  • 为每个视口捕获所有必需的截图
为选定视口集合中的每个必需视口，捕获以下截图：
  • 完整界面
  • 每个主要区块
  • 任何与参考素材视觉差异的区域
每次验证都必须使用计划中声明的精确视口尺寸。 视口尺寸必须与计划完全匹配。 必须为每个视口捕获所需截图。
素材输出要求：
  • 为每个视口将捕获素材和验证输入文件保存到磁盘
  • 为每个视口运行
    ./scripts/validate-visual.sh
    并保存JSON输出（例如
    validation/<viewport>.json
    ）
  • 将验证器JSON素材作为数值标准

Phase 9, visual validation

阶段9：视觉验证

Compare the implementation screenshots against the reference for each required viewport.
Check specifically for:
  • top spacing
  • horizontal page padding
  • card width
  • section spacing
  • inner card padding
  • text size differences
  • text weight differences
  • line-height differences
  • incorrect colors
  • overly rounded or insufficiently rounded corners
  • shadow mismatch
  • button height mismatch
  • icon placement mismatch
  • row density mismatch
  • alignment drift
Also run objective diff checks and record numeric results. Use the validation flow and reporting format in 
references/validation-playbook.md
. For LLM-facing updates, first project validator artifacts into a compact summary with 
./scripts/summarize-validation.sh
.
Validation profiles:
  • lenient
    (allowed only when explicitly justified)
  • portable
    (default for cross-renderer work)
  • strict
    (default for same-renderer work)
  • ultra
    (opt-in only, never default)
Profile selection rules:
  • use 
    strict
    by default when source and target use effectively the same renderer and font stack
  • use 
    portable
    by default when source and target render differently, such as browser to React Native
  • use 
    ultra
    only when the user explicitly asks for it and conditions are controlled (same renderer version, same OS, same DPR, same fonts, same capture pipeline)
  • use 
    lenient
    only when hard constraints prevent higher-fidelity matching; record the exact blocker and why higher profiles are not achievable
Portable interpretation:
  • portable
    MUST allow only renderer-level drift
  • portable
    MUST NOT relax annotated design decisions in the 
    Must-match list
Validation artifact priority:
  • if user-marked comparison screenshots are provided, they MUST be treated as primary validation artifacts
  • generic visual impression SHOULD be used only as supplemental context
Marked issue resolution:
  • every marked issue MUST end in exactly one status: 
    fixed
    , 
    accepted_by_user
    , or 
    renderer_only_drift
  • the validation report MUST include a yes/no checklist entry for each marked issue
  • the validation report MUST include a component-property table with columns: component, property, desired value, actual value, drift, result, reason
  • each table row result MUST be one of: 
    good
    , 
    bad
    , 
    bad_with_reason
  • renderer_only_drift
    MUST include a brief reason
  • a report MUST NOT claim 
    validated
    unless all marked issues have one of the required statuses
  • a report MUST NOT claim 
    validated
    if it has not been updated after the latest visual changes
For every run, report the selected profile and why it was selected before reporting metrics. For every run, report viewport-level metrics for every required viewport.
LLM input projection rules:
  • during iterative loops, provide the model only the projection summary (failed checks, top drifts, deltas, and next actions)
  • do not re-feed full validation JSON unless a targeted slice is required to resolve a specific mismatch
  • when additional detail is needed, load only targeted slices (single viewport, single issue id, or specific check type)
针对每个必需视口，将实现截图与参考素材进行对比。
重点检查：
  • 顶部间距
  • 页面水平内边距
  • 卡片宽度
  • 区块间距
  • 卡片内边距
  • 文本尺寸差异
  • 文本字重差异
  • 行高差异
  • 颜色错误
  • 圆角过度或不足
  • 阴影不匹配
  • 按钮高度不匹配
  • 图标位置不匹配
  • 行密度不匹配
  • 对齐偏差
同时运行客观差异检查并记录数值结果。 使用
references/validation-playbook.md
中的验证流程和报告格式。 对于面向LLM的更新，先使用
./scripts/summarize-validation.sh
将验证器素材投影为简洁摘要。
验证配置文件：
  • lenient
    （仅在明确说明理由时允许使用）
  • portable
    （跨渲染器工作的默认配置）
  • strict
    （同渲染器工作的默认配置）
  • ultra
    （仅可选使用，永不作为默认）
配置文件选择规则：
  • 当源和目标使用基本相同的渲染器和字体栈时，默认使用
    strict
  • 当源和目标渲染方式不同时（如浏览器到React Native），默认使用
    portable
  • 仅当用户明确要求且条件可控时（相同渲染器版本、相同操作系统、相同设备像素比、相同字体、相同捕获流程），才使用
    ultra
  • 仅当硬约束无法实现更高保真度匹配时，才使用
    lenient
    ；需记录确切障碍及无法使用更高配置文件的原因
可移植配置解读：
  • portable
    仅允许渲染器层面的偏差
  • portable
    不得放宽
    必须匹配列表
    中标注的设计决策
验证素材优先级：
  • 若提供用户标记的对比截图，必须将其作为主要验证素材
  • 通用视觉印象仅应作为补充上下文使用
标记问题解决：
  • 每个标记问题必须最终处于以下状态之一：
    fixed
    、
    accepted_by_user
    或
    renderer_only_drift
  • 验证报告必须包含每个标记问题的是/否检查项
  • 验证报告必须包含组件属性表，列有：组件、属性、期望取值、实际取值、偏差、结果、理由
  • 表格每行的结果必须为以下之一：
    good
    、
    bad
    、
    bad_with_reason
  • renderer_only_drift
    必须包含简短理由
  • 若所有标记问题未处于要求状态之一，报告不得声称
    validated
  • 若未在最新视觉变更后更新报告，不得声称
    validated
每次运行都必须先报告选定的配置文件及选择理由，再报告指标。 每次运行都必须报告每个必需视口的视口级指标。
LLM输入投影规则：
  • 迭代循环期间，仅向模型提供投影摘要（未通过检查、主要偏差、增量及下一步操作）
  • 除非需要解决特定不匹配项，否则不得重新输入完整验证JSON
  • 需要额外细节时，仅加载目标片段（单个视口、单个问题ID或特定检查类型）

Phase 10, refine

阶段10：优化

Adjust the code to remove visible mismatches.
If a mismatch reveals the specification was incomplete or wrong, update the specification.
Repeat:
  • implement
  • run
  • capture
  • compare
  • refine
until obvious differences are gone or a hard platform limitation blocks perfect replication.
At least one full 
capture -> compare -> fix -> re-capture
loop MUST occur after the last substantive UI edit. The refine loop MUST run at least once and MUST NOT run more than 10 times.
If unresolved mismatches remain after 10 loops, the report MUST include a detailed unresolved section with:
  • each unresolved issue
  • current desired vs actual state
  • what was tried
  • why the issue is hard to fix
  • whether it is likely renderer-only, asset-limited, data-limited, or implementation-limited
  • the recommended next action for each unresolved issue
If blocked, document the limitation and the remaining discrepancy.
Iteration reporting rules:
  • each refine loop MUST produce an 
    iteration
    report block from projection output
  • iteration report SHOULD include changed statuses and failing rows only
  • full report sections and exhaustive tables are required only in the 
    final
    report mode at handoff
调整代码以消除可见的不匹配项。
若不匹配项显示规格说明不完整或有误，请更新规格说明。
重复以下步骤：
  • 实现
  • 运行
  • 捕获
  • 对比
  • 优化
直到明显差异消失，或平台硬限制阻碍完美复刻。
最后一次实质性UI编辑后，必须至少运行一次完整的
捕获 -> 对比 -> 修复 -> 重新捕获
循环。 优化循环必须至少运行一次，且不得超过10次。
若10次循环后仍存在未解决的不匹配项，报告必须包含详细的未解决章节，内容包括：
  • 每个未解决问题
  • 当前期望与实际状态
  • 已尝试的解决方案
  • 问题难以修复的原因
  • 属于仅渲染器、资源受限、数据受限还是实现受限
  • 每个未解决问题的建议下一步操作
若受阻，请记录限制条件及剩余差异。
迭代报告规则：
  • 每个优化循环必须生成来自投影输出的
    iteration
    报告块
  • 迭代报告应仅包含状态变更和未通过行
  • 完整报告章节和详尽表格仅在交付时的
    final
    报告模式中需要

Definition of done

完成定义

The skill is done only when all of the following are true:
  1. A concise execution plan exists.
  2. A detailed measurement-based UI specification exists.
  3. The UI is implemented in code.
  4. The rendered output has been compared visually to the reference.
  5. A validation profile is selected using the profile selection rules and is recorded in the report.
  6. Objective validation metrics are recorded and all required thresholds pass for the selected profile.
  7. If 
    lenient
    is used, the blocker and reason are explicitly documented.
  8. Asset parity status for fonts and icons is documented, and any fallback usage has explicit user approval recorded.
  9. The acceptance contract exists and includes 
    Must-match list
    , 
    Ignore list
    , and 
    Portable-allowed drift
    .
  10. If user-marked comparison screenshots are provided, they are used as the primary validation artifact.
  11. Every marked issue is resolved as 
    fixed
    , 
    accepted_by_user
    , or 
    renderer_only_drift
    with reason.
  12. The validation report is updated after the latest visual changes.
  13. At least one full 
    capture -> compare -> fix -> re-capture
    loop has run after the last substantive UI edit.
  14. The validation report includes a component-property table with desired value, actual value, drift, and result for each validated property.
  15. All required viewports in the selected viewport set pass validation.
  16. No obvious mismatches remain in spacing, typography, colors, border radius, alignment, or section sizing.
  17. The final response includes an explicit "I believe this is done" statement.
  18. The final response includes side-by-side reference and actual-app images for user review.
  19. The final response asks the user to verify completion and, if not complete, to specify what was missed.
"Roughly similar" is not done. "Good enough" is not done. "Framework-idiomatic but slightly different" is not done.
仅当满足以下所有条件时，技能才算完成：
  1. 存在简洁的执行计划。
  2. 存在基于测量的详细UI规格说明。
  3. UI已通过代码实现。
  4. 已将渲染输出与参考素材进行视觉对比。
  5. 已根据配置文件选择规则选定验证配置文件并记录在报告中。
  6. 已记录客观验证指标，且所有必需阈值均符合选定配置文件要求。
  7. 若使用
    lenient
    ，已明确记录障碍及理由。
  8. 已记录字体和图标资源一致性状态，且任何备选资源使用均已获得用户明确批准并记录。
  9. 存在验收约定，包含
    必须匹配列表
    、
    忽略列表
    和
    可移植允许偏差
    。
  10. 若提供用户标记的对比截图，已将其作为主要验证素材。
  11. 每个标记问题均已解决为
    fixed
    、
    accepted_by_user
    或
    renderer_only_drift
    并附理由。
  12. 已在最新视觉变更后更新验证报告。
  13. 最后一次实质性UI编辑后，已至少运行一次完整的
    捕获 -> 对比 -> 修复 -> 重新捕获
    循环。
  14. 验证报告包含组件属性表，列有每个验证属性的期望取值、实际取值、偏差和结果。
  15. 选定视口集合中的所有必需视口均通过验证。
  16. 间距、排版、颜色、边框圆角、对齐或区块尺寸无明显不匹配项。
  17. 最终回复包含明确的“我认为任务已完成”声明。
  18. 最终回复包含参考素材与实际应用的并排对比图供用户审核。
  19. 最终回复请求用户验证完成情况，若未完成，请指明遗漏内容。
“大致相似”不算完成。 “足够好”不算完成。 “符合框架惯例但略有不同”不算完成。

Failure modes to avoid

需避免的失败模式

Do not do any of the following:
  • implement from memory after a quick glance at the design
  • skip the specification
  • use generic spacing like 16 everywhere because it feels right
  • use default font sizes because they are close
  • replace measured colors with theme colors
  • auto-pick font or icon fallbacks without user approval
  • claim validation using a stale report from before the latest visual changes
  • ignore marked comparison screenshot issues without resolving them as 
    fixed
    , 
    accepted_by_user
    , or 
    renderer_only_drift
  • make subjective UX improvements
  • stop after the first pass
  • declare success without screenshot comparison
  • end without explicit user verification request and missed-detail prompt
请勿执行以下操作：
  • 快速浏览设计后凭记忆实现
  • 跳过规格说明
  • 因感觉合适而统一使用16px之类的通用间距
  • 因默认字体大小接近而使用默认值
  • 用主题颜色替代测量得到的颜色
  • 未获得用户批准就自动选择字体或图标备选方案
  • 使用最新视觉变更前的旧报告声称已验证
  • 未将标记的对比截图问题解决为
    fixed
    、
    accepted_by_user
    或
    renderer_only_drift
    就忽略它们
  • 进行主观的用户体验优化
  • 首次实现后就停止
  • 未进行截图对比就宣告成功
  • 未明确请求用户验证及提示遗漏细节就结束任务

Example invocation phrases

示例调用语句

Use pixel-perfect to copy this screen exactly
Use pixel-perfect to recreate this Figma preview in React Native
Use pixel-perfect to clone this clickable demo without redesigning it
Use pixel-perfect to port this web design into native while preserving the look
使用pixel-perfect精确复制此界面
使用pixel-perfect将此Figma预览还原为React Native界面
使用pixel-perfect克隆此可点击演示，无需重新设计
使用pixel-perfect将此Web设计迁移到原生平台，同时保留外观

Expected behavior summary

预期行为总结

This skill turns a vague prompt like "copy this design" into a strict process:
  • inspect the source
  • measure the source
  • write a plan
  • write a detailed specification
  • implement from the specification
  • run the target
  • capture screenshots
  • compare against the reference
  • refine until matched
This skill does not ask the agent to be creative. It asks the agent to be precise.
本技能将“复制此设计”之类的模糊提示转化为严格流程：
  • 检查源素材
  • 测量源素材
  • 编写计划
  • 编写详细规格说明
  • 根据规格实现
  • 运行目标
  • 捕获截图
  • 与参考素材对比
  • 优化直到匹配
本技能不要求代理具备创造力，而是要求代理具备精准性。