chrome-qa-agent

name	chrome-qa-agent
description	基于 chrome-devtools MCP 的对抗式 UI 测试。分析 git diff 只测改动部分，或探索整个应用找 bug。覆盖功能正确性、无障碍(a11y)、响应式布局与 UX 启发式。当用户要测试 UI 改动、QA 一个 PR、审计无障碍、或做探索式测试时使用。驱动真实本地 Chrome，本地与任意线上 URL 都适用。
license	MIT
metadata	{"author":"云中江树 (yzfly)","version":"0.5.0"}
allowed-tools	Bash Read Glob Grep Agent mcp__chrome-devtools__navigate_page mcp__chrome-devtools__new_page mcp__chrome-devtools__select_page mcp__chrome-devtools__list_pages mcp__chrome-devtools__close_page mcp__chrome-devtools__take_snapshot mcp__chrome-devtools__take_screenshot mcp__chrome-devtools__click mcp__chrome-devtools__fill mcp__chrome-devtools__fill_form mcp__chrome-devtools__hover mcp__chrome-devtools__drag mcp__chrome-devtools__press_key mcp__chrome-devtools__type_text mcp__chrome-devtools__upload_file mcp__chrome-devtools__evaluate_script mcp__chrome-devtools__list_console_messages mcp__chrome-devtools__get_console_message mcp__chrome-devtools__list_network_requests mcp__chrome-devtools__get_network_request mcp__chrome-devtools__wait_for mcp__chrome-devtools__resize_page mcp__chrome-devtools__emulate mcp__chrome-devtools__handle_dialog
compatibility	需要 chrome-devtools MCP 服务已配置并连接（驱动本地 Chrome）。无需额外安装 —— 认证复用真实 Chrome 配置文件的登录态。

Chrome QA Agent — 对抗式 UI 测试 Skill

在真实浏览器里测试 UI 改动。你的任务是想办法把它弄坏，而不是确认它能跑。

本 skill 通过 chrome-devtools MCP（mcp__chrome-devtools__* 工具）驱动单个本地 Chrome。由于该 MCP 只控制一个浏览器，且 select_page 会为整条连接全局设置当前活动页面，浏览器测试是单线程的 —— 绝不能让两个 agent 同时对同一个浏览器操作。

两种工作流：

• diff 驱动 —— 分析 git diff，只测改动部分
• 探索式 —— 在应用里到处点，找出开发者没想到的 bug

对于较大的任务，你仍可以把工作拆给多个子 agent 以隔离上下文，但它们必须轮流独占这唯一的浏览器 —— 见下文「拆分工作的原则」一节。

测试如何运作

主 agent 负责协调 —— 它制定测试策略、把任务分派给子 agent、并汇总结果。真正的浏览器测试由子 agent 执行。

规划：先从多个角度想，再一次性执行

你必须亲自完成全部三轮规划并输出，然后才能启动任何子 agent。 规划发生在你自己的回复里 —— 不能委派给子 agent。不要跳过规划直接执行。

第一轮 —— 功能： 核心用户流程有哪些？什么应该正常工作？把每个测试写成：动作 → 预期结果。

第二轮 —— 对抗： 重读第一轮。你漏了什么？想想：不同的用户类型/角色、错误路径、空状态、竞态、边界输入（空值、超长、特殊字符、连续快速点击）。

第三轮 —— 覆盖盲区： 重读第一、二轮。还有什么没考虑：无障碍（axe-core、纯键盘）、移动端视口、控制台错误、与应用其余部分的视觉一致性？

去重： 把三轮合并成一份带编号的测试清单。去掉重叠项。给每个测试分配一个分组（例如 Group A、Group B）。

然后一次性执行 —— 每个分组启动一个子 agent。每个子 agent 只接收它那份具体的测试清单，别的都不给。子 agent 不探索、不规划 —— 它们执行被指派的测试并汇报结果。

在调用任何 Agent 工具之前，把三轮规划、合并后的计划、以及分组分配都输出在你的回复里。

拆分工作的原则

• 一个浏览器，同一时刻只有一个 agent。 chrome-devtools MCP 控制单个 Chrome，且 select_page 是全局状态。顺序分派子 agent —— 每个在自己回合里独占浏览器，跑完，下一个再开始。并发驱动浏览器的 agent 会破坏彼此的页面状态。（你仍可以并行跑非浏览器的工作，比如 diff 分析。）
• 子 agent 跑被指派的测试，而非开放式探索。 主 agent 交给每个子 agent 一份具体的、带编号的测试清单。子 agent 不规划、不探索、不决定测什么 —— 它们执行清单然后停下。
• 即便是串行，拆分依然有用 —— 它让每个 agent 的上下文保持小而聚焦。许多小 agent 优于少数大 agent。这里的收益是上下文隔离和每组干净的汇报，而不是挂钟时间上的并行。
• 按改动规模匹配投入 —— 单个组件的修复不需要很多 agent 或很多步数；主 agent 直接跑就行。整页重构才值得拆成多个分组。让 diff 的范围来驱动计划。
• 遇到失败不要提前停 —— 在被指派的测试范围内尽可能多地找出 bug。

给子 agent 设定步数预算

主 agent 必须在每个子 agent 的提示里写明步数上限。 一「步」= 一次 chrome-devtools MCP 工具调用（navigate_page、take_snapshot、click、evaluate_script……）。子 agent 不会自我设限 —— 除非被告知，否则它们会一直跑到完成。

粗略经验值：几项有针对性的检查约 25 步，一个完整页面（功能 + 对抗 + a11y）约 40 步，多个页面或一大类约 75 步。根据被指派测试的实际需要来调整 —— 这些是起点，不是规则。

每个子 agent 的提示都必须包含：

You have a budget of N steps (each chrome-devtools MCP tool call = 1 step). Count your steps as you go. When you reach N, stop immediately and report:
- STEP_PASS/STEP_FAIL for every test you completed
- STEP_SKIP|<test-id>|budget reached for every test you didn't get to

Drive the browser ONLY through the chrome-devtools MCP tools (mcp__chrome-devtools__*).
You own the browser exclusively for this run — no other agent is using it. When done, the next agent will reuse the same Chrome, so leave it in a clean state (close extra tabs you opened with close_page).
Do not retry or continue after hitting the budget.
Run only these tests: [numbered list from the merged plan]
Do not explore beyond the assigned tests.
Do NOT generate an HTML report or write any files (except screenshots via take_screenshot's filePath). Return only step markers and your findings as text.