用途：在 UI 发生变化或被要求“测试这个”“QA”“检查页面”时，执行基于浏览器的质量检查。需要宿主提供浏览器自动化能力；不适合非 UI 类检查。
主要能力与使用方式：
- 加载上下文：从 CLAUDE.md 或 AGENTS.md 读取 verbs 配置，解析 {learnings_dir}（默认 docs/learnings）；在 learnings 目录中查找与 UI 或改动组件相关的 type: pitfall；如 docs/briefs/ 存在简要说明则读取以了解预期行为。
- 规划测试：依据 diff、简要说明或用户指令，分三轮梳理测试。第一轮功能性：核心用户流程，写成“操作 -> 预期结果”，并列出改动的页面/URL 及改动后应可用的功能。第二轮对抗性：回看第一轮，补充错误路径、空状态、加载状态、边界输入（空、超大、特殊字符、快速点击）、重复提交、流程中按 Escape、纯键盘导航。第三轮覆盖缺口（小改动可跳过）：无障碍（键盘导航、焦点管理）、移动端视口断点、交互后的控制台报错。合并为一份无重叠的编号测试列表。若不清楚测试对象，询问用户应测试哪些流程。
- 执行测试：小改动（1-2 组）直接测；合并列表有 3 组以上且宿主提供隔离浏览器 worker 时，可分派并行子代理，各 worker 使用独立浏览器会话，无法证明隔离则顺序执行。子代理提示需包含编号测试列表、断言协议和步数预算（针对性检查约 25、整页约 40、多页约 75）。主代理不共享浏览器会话，只协调、合并结果并输出最终摘要。子代理超出预算时接受部分结果，未覆盖测试记 STEP_SKIP。 断言协议：每个测试步骤输出结构化标记 STEP_PASS|<step-id>|<evidence>、STEP_FAIL|<step-id>|<expected> -> <actual>、STEP_SKIP|<step-id>|<reason>。step-id 为简短标识，evidence 为观察到的通过证据。验证强度依次为：确定性检查（eval 返回结构化数据）、快照元素匹配、操作前后对比、截图与视觉判断（最弱，仅用于无障碍树无法捕捉的视觉属性）。 失败输出：每个 STEP_FAIL 需附截图与缺陷报告，位置与 [BUG] 模板见 skills/engineering/qa/lib/test-output-format.md，其 Action: AUTO-FIX | ASK 字段用于第 4 步。全部测试后输出摘要行：Tests: N | Passed: N | Failed: N | Skipped: N | Pass rate: N%。
- 修复：按 test-output-format.md 的路由约定执行每个缺陷报告的 Action 字段，不在此处二次分类。AUTO-FIX 后重跑受影响流程；ASK 项作为待决策事项，不得报告为已修复。
- 沉淀学习：若发现 UI 模式或浏览器特有的坑，按 lib/learning-format.md 生成一条 type: pitfall 候选；不要写入 {learnings_dir}，持久化由宿主/项目负责。否则明确说明“no learning warranted”。常见示例：“该组件在移动端视口下布局错乱”“表单校验在用户尚未输入完就触发”“慢网络下缺少加载状态”。
限制：需要宿主提供浏览器自动化；并行执行需要宿主提供隔离 worker 且能证明会话隔离；小改动不启用子代理；资料未提供具体价格、平台支持范围与安装命令。