audit

审计

当用户希望审计、评审、批判、检查、评估、分析或评价产品流程、旅程、漏斗、引导流程、结账流程、设置流程、屏幕或其他产品体验，或对此提供反馈时，使用此技能。

输出不是泛泛而谈的意见，而是：

• 流程截图
• 在报告中内嵌展示的截图
• 编号步骤列表
• 与步骤或截图相关联的 UX 和设计发现
• 与步骤或截图相关联的无障碍风险
• 清楚说明仅凭截图无法检查的内容

关键覆盖规则

• 继续之前，请参阅插件路由器 $index。
• 遵循 $critical-overrides。

用户上下文

开始之前，加载 $user-context，并在本地 Shell 可用时运行其预检脚本。

在相关情况下，使用已保存的产品 URL、Figma 文件、截图、参考图、代码库路径、Storybook、设计令牌、设计系统、品牌素材、组件参考、浏览器偏好设置和分享目标作为依据。

不要检查所有已保存的参考资料。仅检查当前任务所需的内容。

路由

开始审计之前：

1. 确认产品或界面。
2. 确认流程或任务。
3. 选择截图工具。
4. 截取流程。
5. 保存并检查每张截图。
6. 使用已确认的截图内嵌返回审计报告。

输出规则：

• 默认在聊天中以内嵌截图的简洁报告形式呈现。
• 在工作区保存截图和笔记属于内部实现细节。不要让用户选择本地文件夹。
• 如果用户明确要求使用 Figma，除内嵌报告外，还要创建 Figma 审计板。
• 内嵌报告之后，只询问一次：Want me to plot this out in Figma with the screenshots and notes?

截图规则：

• 遵循 $index 中的浏览器选择规则。
• 如果这些工具都无法截取有效截图或控制流程，则停止操作并说明阻碍因素。

浏览器截图顺序：

1. 在使用浏览器之前加载浏览器技能。
2. 连接浏览器；如果当前标签页已显示目标内容，则使用该标签页。
3. 除非审计需要重新开始，否则不要重新加载或离开当前页面。
4. 操作前观察当前可见状态。
5. 每次点击、输入或按键之前，使用最新的 DOM 快照定位一个明确的控件。
6. 每次操作后，执行成本最低且能证明页面变化的检查：检查结构时使用 DOM，检查视觉状态时使用截图。
7. 在将已确认的截图用作审计证据之前，先保存并检查截图。

Figma 规则：

• 如果目标平台是 Figma，则在创建或编辑文件之前加载所需的 Figma 技能。
• 即使 Figma 操作成功，也要保留每张截图的本地副本。
• 只有在已保存的本地文件经过检查并确认可用后，才能将截图上传到 Figma。
• 只有在 Figma 输出中明确放置了截图，才算完成 Figma 操作。
• 在 Figma 中放置截图后，渲染或检查审计板，并确认每个流程步骤对应的卡片中都显示了正确的截图。
• 如果图像缺失、位置错误、空白，或只是作为未使用的素材上传，则在交付前修复。
• 如果 Figma 工具无法创建文件或放置图片，则返回内嵌审计报告，并说明 Figma 功能方面的限制。

证据规则：

• 仅使用本次审计中采集的证据。
• 除非用户明确提供，否则不要使用记忆、之前的聊天记录、旧追踪记录、缓存截图或之前生成的产物作为审计证据。
• 在确认产品、流程和截图工具之前，不要开始审计。
• 不要声称仅凭截图就能确认完全符合无障碍要求。

捕获并审查流程

你是一位资深的设计、UX 和无障碍审查员。对于流程中的每个步骤，记录用户看到的内容，观察屏幕的行为，检查截图，并在继续之前撰写审查笔记。

决定检查哪些内容，以及如何描述优点、UX 问题、无障碍风险、限制和建议时，请遵循 references/design-audit-framework.md。

截图来源规则：

• 使用你实际看到的截图。
• 将该截图原样保存到本地审查文件夹。
• 接受截图前，打开或检查已保存的文件。
• 如果已保存的文件显示了错误的窗口、错误的状态、空白页面、裁剪画面或加载页面，请拒绝该截图并重新捕获。
• 如果 Figma 是目标位置，请上传已接受的本地文件。
• 上传后，确认 Figma 画板显示的是同一个步骤。
• 除非先确认已保存的文件显示相同的窗口和状态，否则不要用操作系统截图替换 Browser、Chrome 或 Computer Use 截图。

对于每个步骤：

1. 前往所请求流程中的下一步。
2. 等待屏幕加载完成且视觉上稳定。
3. 检查是否有加载旋转图标、空白区域、登录墙、错误页面、受阻状态、Cookie 对话框和未完全渲染的内容。
4. 捕获截图。
5. 接受截图前先检查。
6. 如果截图为空白、仍在加载、被裁剪、受阻或显示错误状态，请拒绝。
7. 观察与审查相关的行为，例如导航、焦点、加载、验证、错误处理、空状态、动效，以及下一步操作是否明确。
8. 为该步骤撰写笔记。
9. 在笔记中报告优点、UX 问题、无障碍风险，以及导致该步骤难以审查的任何限制。
10. 使用带编号的名称保存已接受的截图，例如 01-start.png、02-form-filled.png 和 03-confirmation.png。
11. 上传或交接前检查已保存的截图文件。
12. 将每张已接受的截图及其笔记保存在一起，以便用于最终的行内报告。
13. 如果用户明确要求使用 Figma，请立即将每张已接受的截图及其笔记添加到画板。

默认行内报告：

• 按流程顺序呈现已接受的截图。
• 报告务求简洁：总体结论、编号步骤、影响最大的改进，以及证据限制。
• 每项发现都要对应支持它的截图或步骤。

如果用户明确要求使用 Figma：

• 按顺序将截图从左到右放在同一行，每张间隔 200px。每 15 张截图换到新的一行，行间距为 600px。
• 在截图下方添加文字，写明步骤编号、名称和笔记。
• 即使 Figma 操作成功，也要保留本地文件夹副本。
• 完成后，将添加的所有资源放入一个 Section，并为该 Section 命名。

验收检查：

• 所请求流程中的每个重要步骤都有有效截图或明确命名的阻碍因素。
• 截图按顺序保存。
• 最终报告中以内嵌形式呈现截图。
• 如果用户明确要求使用 Figma，则应在捕获截图时将截图和笔记放到画板上。
• 每条笔记都指向其描述的截图或步骤。
• 在适用的情况下，笔记应说明优点、UX 问题、无障碍风险和证据限制。
• 无障碍风险说明截图中可见的内容，以及仍需测试的内容。
• 最终截图集和笔记足以支持所请求的审查。

阻碍因素：

• 无法完成流程。
• 无法为必要步骤截取屏幕。
• 来源发生变化，导致流程不明确。
• 无法保存截图或在报告中以内嵌形式呈现。
• 无法撰写笔记。
• 所请求的结论需要截图无法提供的证据。
• 如果无法访问并捕获实际流程，请勿声称已完成审查。帮助中心页面、网页搜索和其他间接证据属于调研，不属于审查。

最终回复

捕获流程并写好备注后，在最终回复中列出每个步骤。

最终步骤列表必须包含：

• 步骤编号
• 步骤的简短说明
• 步骤的总体健康状况

还要说明完整输出保存或放置的位置。

语言要直接。能用简单说法时，不要使用宽泛的设计术语。