| name | dev-test |
| description | 测试统一入口 skill。识别用户测试意图后路由到对应子执行手册（AGENT.md）。覆盖：写用例、冒烟、集成/e2e、UI 视觉、bug 回归、bug 增量冒烟/集成/UI。当用户提到"测试、写用例、冒烟、集成测试、e2e、UI 视觉、bug 回归、bug 验证、修复验证、增量测试、补测试、覆盖矩阵"等任意测试相关请求时触发。不处理：代码审查（review）、安全审计（security-review）、性能压测、负载测试。 |
Dev Test — 测试统一路由入口
本 skill 是 skills/dev-test/ 下所有测试执行手册的统一路由入口。
负责意图识别、上下文加载、分发执行。子目录的 AGENT.md 不会被 Claude Code 单独注册为 skill，必须由本入口主动读取并执行。
执行协议（强制顺序）
每次触发本 skill，必须严格按以下顺序执行，每步开始前输出状态声明，完成后输出结果声明。
Step 1 — 加载内核
开始声明：
[dev-test] ⏳ Step 1/4 加载测试治理内核...
读取 skills/dev-test/test-governance-core/AGENT.md，作为本轮所有测试任务的公共底座。
内核包含：上下文发现、技术栈识别、知识库降级、用例 schema、真实环境阻断、增量优先、报告口径。
⚠️ 真实环境硬约束：内核要求所有测试默认使用真实环境、真实账号、真实服务、真实数据。缺失任一必要信息时，必须暂停执行并主动向用户追问缺失项（明确说出缺什么、为什么需要、用户应如何提供），等用户补齐后再继续当前流程；不得直接退出、不得只丢一份"待澄清清单"了事、不得用 mock / dry-run / 单测 / 离线模式替代真实验证。本入口在路由前必须把这条约束传递给被调用的执行手册。
⚠️ 操作与编码硬约束：除冒烟测试外，其他测试场景必须模拟人工操作执行验证，覆盖真实浏览器、真实客户端、真实 CLI 或等价用户路径；接口调用只能作为辅助证据，不得作为唯一验证方式。所有命令、脚本、报告、日志和证据文件的输入输出必须统一使用 UTF-8 编码。
完成声明：
[dev-test] ✅ Step 1/4 内核加载完成
Step 1.5 — Kimi WebBridge 健康检查（仅当本轮涉及浏览器操作时）
触发条件：路由命中以下任一项时强制执行：
ui-tester（视觉比对）bug-ui-delta-tester（UI bug 增量验证）integration-tester 且本轮包含浏览器交互（导航 / 点击 / 表单 / 读页面 / 截图等）
开始声明：
[dev-test] ⏳ Step 1.5 检测到浏览器意图，正在校验 Kimi WebBridge...
执行：
~/.kimi-webbridge/bin/kimi-webbridge status
结果路由与声明：
| 观察到 | 状态声明 | 处理方式 |
|---|
running: true 且 extension_connected: true | [dev-test] ✅ Step 1.5 Kimi WebBridge 健康，继续执行 | 进入 Step 2 |
command not found / 二进制缺失 | [dev-test] ⚠️ Step 1.5 Kimi WebBridge 未安装，等待用户确认... | 主动告知 + 询问是否安装 + 用户确认后执行 curl -fsSL https://cdn.kimi.com/webbridge/install.sh | bash |
running: false | [dev-test] ⏳ Step 1.5 守护进程未启动，正在启动... | 执行 ~/.kimi-webbridge/bin/kimi-webbridge start（幂等），启动后重新校验并输出结果声明 |
running: true 且 extension_connected: false | [dev-test] ⚠️ Step 1.5 扩展未连接，等待用户操作... | 引导用户打开浏览器或到 https://www.kimi.com/features/webbridge（中文：https://www.kimi.com/zh-cn/features/webbridge）安装扩展 |
| 用户拒绝安装 | [dev-test] ℹ️ Step 1.5 已跳过 Kimi WebBridge，启用降级方案 | 项目已有 Playwright/Cypress 时复用，否则只生成手工步骤清单，明确告知限制范围 |
| 更深层故障 | [dev-test] ❌ Step 1.5 Kimi WebBridge 故障，转交专项排查 | 转交 kimi-webbridge skill 的 references/operations.md 处理 |
⚠️ 安装属于中等风险动作，必须等用户明确确认后才执行。不得未经同意直接拉取并执行远程脚本。
详细引导流程见 test-governance-core/references/ui-tooling.md → "Kimi WebBridge 缺失时的引导流程"。
Step 2 — 意图识别与路由
开始声明：
[dev-test] ⏳ Step 2/4 识别测试意图...
按下述"路由判定规则"识别用户意图。
完成声明（路由确定后输出）：
[dev-test] ✅ Step 2/4 路由确定：识别意图 <X>，加载执行手册 <path/AGENT.md>
若触发歧义澄清，输出：
[dev-test] ⚠️ Step 2/4 意图存在歧义，等待用户确认...
等用户确认后再输出路由完成声明。
若触发多重意图队列，输出：
[dev-test] ℹ️ Step 2/4 检测到多重意图，队列：A → B → C
Step 3 — 执行测试手册
开始声明：
[dev-test] ⏳ Step 3/4 开始执行：<手册名称>
按路由结果读取对应的 AGENT.md，把内核约束 + 用户原始上下文 + 手册流程合并执行。
手册内部每个子步骤也需输出状态，格式：
[dev-test] ⏳ <手册名> / <子步骤描述>...
[dev-test] ✅ <手册名> / <子步骤描述> 完成
[dev-test] ⚠️ <手册名> / <子步骤描述> 需要用户补充信息，等待中...
[dev-test] ❌ <手册名> / <子步骤描述> 失败：<原因>
多重意图队列中，每个手册执行前额外输出进度：
[dev-test] ▶ 队列进度：正在执行 2/3 — <手册名称>
完成声明：
[dev-test] ✅ Step 3/4 <手册名称> 执行完成
若执行被阻断（真实环境信息缺失）：
[dev-test] ⏸ Step 3/4 执行已暂停，等待用户补充：<具体缺失项>
Step 4 — 产出落盘
开始声明：
[dev-test] ⏳ Step 4/4 正在写入报告和证据...
按内核要求输出报告到被测项目的 test-governance/reports/，证据落 test-governance/evidence/，默认增量不覆盖。
完成声明：
[dev-test] ✅ Step 4/4 产出落盘完成
📄 报告：test-governance/reports/<文件名>
🗂 证据：test-governance/evidence/<路径>（如有）
全流程结束声明：
[dev-test] 🏁 测试任务完成 | 手册：<名称> | 状态：<通过/失败/阻断> | 报告：<路径>
路由判定规则
第一判定：是否涉及 Bug 实体
判定 Bug 系列的硬条件（满足任一即为 Bug 系列）：
- 用户给出具体 bug 描述、症状、报错日志、截图、复现步骤
- 用户提供修复 diff / commit / PR 链接，明确说"修复了 X 问题"
- 用户引用 bug 编号 / Jira 工单号 / issue 链接
- 用户说"复现、回归、修复后验证、防回归"且指向具体故障
仅"我刚改了代码、帮我测一下"不算 Bug 系列——这是常规改动测试，按"第二判定"处理。
第二判定：测试类型分类
| 用户意图特征 | 路由目标（AGENT.md 路径） |
|---|
| Bug 系列 | |
| 复现 bug、修复后回归、为 bug 沉淀长期回归用例、防回归资产 | bug-regression-tester/AGENT.md |
| bug 修复后跑哪些冒烟、最小启动验证、bug 是否破坏 P0 主流程 | bug-smoke-delta-tester/AGENT.md |
| bug 影响哪些接口、修复后接口联调、服务协作受影响范围 | bug-integration-delta-tester/AGENT.md |
| bug 修复后页面验证、UI bug 回归、视觉/交互受影响 | bug-ui-delta-tester/AGENT.md |
| 常规系列 | |
| 写测试用例、补测试清单、生成测试场景、覆盖矩阵、单元测试用例设计 | test-case-writer/AGENT.md |
| 冒烟测试、发布前快速检查、服务可用性、健康检查 | smoke-tester/AGENT.md |
| 集成测试、接口联调、服务协作、模块集成、e2e、UAT、端到端 | integration-tester/AGENT.md |
| UI 视觉验证、设计稿比对、像素级对比、视觉回归、Figma 比对 | ui-tester/AGENT.md |
| 内核直调 | |
| 用户明确说"治理规则、测试框架配置、知识库接入策略、报告口径" | test-governance-core/AGENT.md（直接执行） |
第三判定：歧义澄清
碰到下列高频歧义场景时，先停下来询问用户，不要默认选一个：
| 歧义场景 | 必须澄清的问题 |
|---|
| "修复后验证一下" | 只跑最小冒烟（bug-smoke-delta）还是要沉淀长期回归资产（bug-regression）？ |
| Bug 同时触及接口和页面 | 只跑接口集成增量（bug-integration-delta），还是同时跑 UI 增量（bug-ui-delta）？ |
| "完整测一遍" | 串行跑：smoke → integration → ui？还是只挑核心路径？ |
| "测一下我刚改的代码" | 你想要：(a) 写用例 (b) 跑冒烟 (c) 跑集成 (d) 跑 UI？ |
| 用户给了 bug 描述但没说测试类型 | 你想要：(a) 复现 + 回归资产 (b) 增量冒烟 (c) 增量集成 (d) 增量 UI？ |
第四判定：多重意图串联
用户一次说多个意图（"补回归 + 跑增量冒烟"、"先写用例再跑集成"）时：
- 拆成有序队列，按用户表述顺序执行
- 每个子手册独立产报告，但合并写入同一份
test-governance/reports/<日期>-combined.md
- 任一子手册触发真实环境阻断，整条队列停止，输出统一阻断报告
- 队列开始前向用户播报：
[dev-test 队列] 将依次执行：A → B → C
第五判定：超出范围
下列请求不接，直接告诉用户走对应专业 skill：
| 请求 | 引导 |
|---|
| 代码审查 / Review | 用 /review 或 review skill |
| 安全审计 / 漏洞扫描 | 用 /security-review 或 security-review skill |
| 性能压测 / 负载测试 / 基准测试 | 不在 dev-test 覆盖范围，建议接专门的压测工具（k6 / JMeter / wrk） |
| 部署验证 / 灰度回滚 | 不在 dev-test 覆盖范围 |
子手册一览（用于兜底询问）
当意图无法匹配任何路由规则时，向用户展示下表并请用户选择：
| 手册 | 一句话说明 | 适用场景 |
|---|
test-case-writer | 生成结构化测试用例矩阵 | 没用例 / 用例不全 / 需要覆盖矩阵 |
smoke-tester | 最小可用性冒烟 | 发布前 / 联调前 / 快速健康检查 |
integration-tester | API / 服务 / DB 模块协作验证（含 e2e） | 接口联调 / 跨服务契约 / 端到端 |
ui-tester | 设计稿与实际 UI 视觉比对 | Figma 对比 / 视觉回归 |
bug-regression-tester | bug 复现 + 修复后回归 + 沉淀资产 | 长期防回归 / Jira 工单收尾 |
bug-smoke-delta-tester | bug 修复后最小冒烟 | 改动小 / 想确认没破坏启动 |
bug-integration-delta-tester | bug 修复后最小集成 | 改动触及接口或服务协作 |
bug-ui-delta-tester | bug 修复后最小 UI 验证 | 改动触及页面 / 组件 / 交互 |
约束
- 本 skill 只做路由 + 内核加载 + 队列编排，不重复实现子手册逻辑。
test-governance-core/AGENT.md 是公共前置内核，每次路由前必须加载；不作为常规路由目标，除非用户明确要"看治理规则"。- 路由后完整传递用户原始上下文，不裁剪、不改写。
- 子目录已统一改名为
AGENT.md，Claude Code 不会单独注册它们；本入口是唯一触发点。
- 真实环境阻断是底线：缺信息就停下问，不许用 mock / dry-run / 离线模式包装成"测试通过"。
- 非冒烟测试必须模拟人工操作：集成、e2e、UAT、UI 功能、回归和 bug 增量验证不得只做接口调用，必须保留真实用户路径证据。
- 编码是底线：所有输入输出、脚本、日志、报告和证据文件必须使用 UTF-8。
