设计 UAT
评审网站视觉实现是否符合设计参考。默认生成英文、问题优先的 HTML 报告；接受用户指定的语言或报告格式。该技能可跨项目复用。项目 URL、框架映射、已接受的偏差、凭据和运行证据不应存放在此技能文件夹中。
从用户给定的范围开始
以用户提供的网站和图稿链接作为初始范围。如果存在合适的项目档案，则复用它；否则直接开始探索，不要求用户提供预先准备好的路径列表或配置。当 Figma 页面代表版本交接时，盘点整个页面并发现每个模块自身的测试路径。提供的网站 URL 是入口点，而非路径限制。尊重显式的全页面范围；记录排除项和被阻塞的状态，而非静默替换为样本。对于未指定的大范围，给出一个有用的评审边界。仅采样一个屏幕并不等于验收了整个模块。
将项目数据保存在当前项目的可写工作空间中，并遵守仓库说明。一个有用的默认结构是 design-uat/<project>/project.json 和 runs/<run-id>/，但应保留已建立的位置。创建映射、构建报告输入或记录重运行时，请参考 project-data.md。
发现实际可用的工具。优先使用 Figma 连接器获取设计结构和尺寸，使用浏览器控制获取实时 UI。必要时使用相关工具说明和前提技能；本技能不提供这些工具。尽可能复用已有的授权登录。如果访问被阻塞，继续执行有用的独立工作，并精确报告哪些状态无法评审。
发现设计到页面的映射
在比较图像之前，先检查设计层级和实时导航。画布上可能包含模块容器、屏幕框架、本地状态示例、注释、备注和备选方案。应识别该结构中的视觉目标，而非将整个文档板导出为屏幕。
阅读相关的注释和本地状态示例。它们可能指定了响应式行为、输入尺寸、截断或主框架未显示的组件细节。使用可见/有效的节点内容；隐藏的组件辅助/错误文本不应仅因存在于树中就视为活跃需求。
区分实际的页面规范与通用交互图示。一个通用的抽屉示例可能揭示现有模块中的差异，但并不能确定每个类别所需的字段。保留有用的跨模块发现及其真实路由、导航上下文和基线限制；除非已知其历史，否则将怀疑为遗留状态标记为未确认。
综合模块上下文、路由、可见页面标题、字段标签、UI 结构和渲染外观进行匹配。在项目数据中记录框架 ID、页面/状态、比较区域、置信度和映射状态。一个 URL 可以对应多个视觉状态。不要将列表、打开的抽屉、聚焦的输入和空状态混为一谈。
对于有充分支持的匹配，若未经人工确认，则标记为推断。将真正模棱两可的选择批量提供给用户，同时继续处理未受阻的情况。将替代/备选设计记录为超出选定范围，并给出原因；名称本身并不确定已接受的版本。在复用之前，验证先前保存的映射是否与当前设计和实时页面一致。
对于大型 Figma 文件，在本地保留原始元数据，并向上下文返回紧凑、浅层的摘要。在提取详细子树或截图之前，先通过已知祖先缩小范围。避免重复加载整个文件。
捕获可比较的证据
在首次捕获或诊断比较问题之前，阅读 evidence-workflow.md。它涵盖了画板溢出、状态匹配、注释排除、动态内容、局部裁剪和截图接受标准。
通过导航、焦点和可逆的输入更改来暴露所需的视觉状态。未经授权，不得仅为获取截图而提交业务变更。如果某个状态需要不可用的数据或写操作，则记录该限制，而非捏造状态。
在兼容的视口、缩放比例和主题下，精确捕获设计区域和浏览器状态。检查字体/内容是否已加载且目标稳定。拒绝瞬态加载捕获，除非加载本身就是要评审的状态。在将截图用于报告之前，先检查保存的截图。保留原始捕获，同时保留任何裁剪、叠加和注释。
基于两张图像共同呈现差异，并在适用时基于 Figma 几何体和浏览器元素边界。将测量值归因于其来源。当 Pillow 可用时，使用 scripts/compare_regions.py 进行可选的原始比例配对裁剪和标记。报告渲染器本身仅需要 Python 标准库。
检查控件行内的关系以及单个维度：相邻间隙、对齐、剩余操作空间以及活动过滤器控件出现时的变化。当有证据或明确的评审者反馈支持时，将共享的布局修正及其视觉后果归为一个稳定的问题。将这种分组与代码级别的根本原因诊断区分开。
区分上下文与缺陷：样本数据、账户身份、展开的导航、全局公告和更高版本的组件都可能改变截图。记录它们；不要静默忽略其布局影响。文本值可能被排除在文案匹配之外，但其换行、溢出和对齐仍可评审。绝不要拉伸截图以隐藏差异或捏造全页相似度分数。
做出可操作的问题发现
根据每项发现所支持的证据对其进行分类：
visual-defect（视觉缺陷）：可重复的视觉故障，例如裁剪、重叠或已确认的实现违规。说明条件和预期来源。baseline-mismatch（基线不匹配）：与提供的参考存在明显差异，可能需确认当前已接受的设计/版本。design-clarification（设计澄清）：观察到的条件，但设计指导不足或有冲突，无法决定是否接受。
保持观察置信度、建议优先级和后续跟踪状态相互独立。不要因为差异明显就将高置信度的截图差异称为已接受的缺陷。使用项目的优先级方案；标注建议，并在决定未解决时让优先级保持未设置。不要虚构负责人、目标发布版本、已批准的偏差、实现完成或成功复测。
每个问题发现都需要：稳定的 ID、页面/状态、简洁的标题、实际结果、预期结果或明确的不确定性、证据依据、建议的操作和复现步骤。附上针对性的比较证据和完整的当前状态捕获。包含相关的 Figma 参考。没有视觉证据的发现是限制或问题，而非已确认的视觉缺陷。
分别记录已完成的检查以及被阻塞/未评审的状态。在重运行时保持相同的问题 ID。仅当有匹配的新证据时才能关闭或标记为已解决；保留先前的观察结果并解释变更后的验收标准。
整合设计评审
默认生成评审草稿，然后在生成开发者交接报告之前整合设计者的决策。收到反馈、修正设计基线或准备正式报告时，请阅读 review-workflow.md。对话中已给出的明确评审和批准已足够；无需再次索要相同的确认。
在项目数据中记录保留、排除、接受、合并、推迟和设计更新决策，并注明来源和范围。设计参考的修正不是实现修复。评审者关于设计变更的反馈本身并不授权编辑 Figma。保留草稿和决策历史；开发者交接报告仅包含保留的行动项，包括任何明确保留的澄清或已有模块的后续跟踪。不要将未分配的优先级、所有权、发布版本或复测字段转化为已确认的值。
交付报告
撰写报告时，请阅读 report-format.md。保持经过验证的阅读顺序：受限上下文 → 简洁的问题注册 → 选定问题的实际/预期视觉证据 → 覆盖范围与评审说明。使视觉证据成为报告的核心，而非独立的附录。避免为每个问题和每个通过的检查重复使用大尺寸截图。
写入 project-data.md 中描述的结构化运行数据，然后执行：
python3 <skill-dir>/scripts/render_report.py <run-dir>/report.json
这将生成独立的 report.html、issue-register.csv 以及（当提供验收标准时）acceptance-checklist.csv。在开发者交接报告中，每个保留的项都需要一个直接的测试 URL、导航/上下文、开发人员行动和可观察的验收标准。渲染器直接支持这些字段；不要通过修补生成的 HTML 来添加它们。渲染器需要 Python 3.9+ 且无需第三方包。它会验证输入/证据，但不会推断评审决策、访问外部系统或将报告发送给开发者。
检查渲染后的报告，包括其问题切换/过滤、图像展开和比较控件。使用可用的本地预览工具打开结果，并遵循其浏览器规则。如有必要，使用无冲突的本地预览，绑定到 loopback；除非被要求，否则不要发布或写入外部系统。在实际可行时，恢复临时的浏览器视口覆盖和测试输入，并报告任何仍处于更改状态的内容。
以对话使用的语言交付报告链接、简洁的覆盖范围和关键结果。解释重要的限制。不要仅仅为了生成已请求的报告而要求批准。对方法的讨论请求不是执行 UAT 运行的请求。