test-assist

name	test-assist
description	写完代码后协助测试 — 写测试用例 + 跑测试 + 失败帮修。触发场景：plan-first 复杂任务（判据见 .claude/rules/im-agent-workflow.md 的任务复杂度分级表）的 plan 用户拍板后，必须主动询问"需要协助测试吗"。用户 yes 后由本 skill 编排 test-writer / test-runner / test-fixer 三个 SubAgent 完成测试闭环。简单任务（单文件改）不触发，避免噪音。

test-assist

把"写完代码"和"测试通过"主动闭环。本 skill 是编排器：决定测什么 / 派哪个 agent / 报告什么；不亲自写测试也不亲自跑。

1. 何时触发

触发条件（同时满足）

• 当前任务被判为复杂（判据见 .claude/rules/im-agent-workflow.md 的「任务复杂度分级」表）
• 用户已拍板 plan
• 改动已经实施完成（不是计划阶段，是代码已经改了）

主动询问话术

plan 拍板后用户改了代码，AI 必问一次：

「这个改动需要协助测试吗？我可以：
 - 写一套测试用例（unit / component / e2e，按改动复杂度选）
 - 跑测试 + 给报告
 - 失败的我帮你修（最多 2 轮，仍失败报告你介入）
 yes / no」

不触发的场景

• 单文件改 / 修注释 / 改文档 / 配置调整 → 不问（避免噪音）
• UI 样式调整 / 一次性 bug 复现 → 不问
• 用户回答 no → 同会话不再重复问（一次拒绝就尊重）

触发后的流程

用户 yes
  ↓
test-assist skill 决定测什么类型：
  - 改了 utils / hooks / 纯函数 → unit
  - 改了 store / service / 多状态组件 → component
  - 改了多页面 flow / 跨路由跳转 → e2e
  ↓
派 test-writer（按类型 override 模型，见下表）
  ↓
test-writer 写完 → test-runner 跑
  ↓
全过 → 报告完成
有失败 → test-fixer 修 → test-runner 重跑（最多 2 轮）
2 轮仍失败 → 上报用户介入

2. 测试类型决策

改动性质	测试类型	派 test-writer 时模型
utils / hooks / 纯函数	unit	Haiku（机械）
store / service / 多状态组件	component	Sonnet（理解上下文）
多页面 flow / 路由跳转 / 表单提交	e2e	Sonnet（多页面）
修 bug（不论改了什么）	防回归测试（与上述类型对应）	按改动性质选

派单时如何 override 模型：调用 Task 工具时把 subagent_type="test-writer"，prompt 里加一句 请用 Haiku 模型完成（机械任务） 或在 main agent 派单约定里指定 model。

3. SubAgent 路由

SubAgent	职责	模型（默认）
test-writer	写 .spec.ts / .test.ts	sonnet（unit 时 main agent override 为 haiku）
test-runner	跑测试 + JSON 解析 + 总结	haiku
test-fixer	失败分析 + 改代码	sonnet

4. 失败修复 2 轮上限（硬约束）

test-runner 跑 → 失败
  ↓
第 1 轮：test-fixer 改 → test-runner 重跑 → 还失败？
  ↓
第 2 轮：test-fixer 改 → test-runner 重跑 → 还失败？
  ↓
**停下来报告用户**：「已尝试 2 次修复仍失败，错误：<spec:line + 一句>，建议你看一下」

为什么限 2 轮：防"AI 改错方向越改越乱"的无限修复循环。3 次没过 = 测试或代码方向有问题，需要人决策。

5. Playwright MCP 用法硬约束

写 e2e 时必读：

做法	决策
❌ Playwright MCP 实时点击 / 输入 / 逐步交互	禁止（114K tokens/次，烧上下文）
✅ MCP 仅用于 navigate + screenshot + console messages	OK（debug 时辅助）
✅ 写 .spec.ts → npx playwright test --reporter=json → 解析报告	强制（4 阶段流水线，~27K tokens/次）

reporter=json 输出文件后让 test-runner 解析 JSON，不要让 main agent 直接看 stdout。

6. SubAgent 模型选择（主 agent 派单时）

参考 .ai/knowledge/ai-manual.md 第 5 节"SubAgent 模型选择"。要点：

• 机械任务（跑测试 / 总结 pass-fail / 简单 unit test 写）→ Haiku
• 编码实现（component test / e2e test / 失败修复）→ Sonnet
• 架构 / 棘手 bug / 大重构 → Opus（test-assist 内部很少用到）

默认 Sonnet，机械任务必须降到 Haiku。

7. 报告格式

测试全部跑完后写一份报告到 .ai/reports/YYYY-MM-DD-<feature>.md，并在对话里给一段精简版：

# 测试报告: <feature> (<date>)

## 测试概览
- 范围: unit + component + e2e
- 通过: X/Y
- 失败: Z

## 失败详情（如有）
1. `<spec>:line <name>` — timeout 等待 selector → 已修：<修法>

## 修复回归
- 重跑: X/Y ✅ / ❌

## 覆盖率（vitest 时）
- `<file>`: X% (lines)

对话里给：「测试报告已写到 .ai/reports/<file>.md。X/Y 通过。<失败 1 句>」不要把整份报告复读。

8. 反模式

• ❌ 简单任务（单文件改）也问"要不要测试"（噪音）
• ❌ 用户已经说 no，下一轮又问一遍（不尊重）
• ❌ 自己跑测试 / 自己写 .spec.ts（应派 SubAgent）
• ❌ Playwright MCP 实时操作浏览器代替写 .spec.ts（114K tokens 浪费）
• ❌ 失败修了 3 次还在试（必须上报）
• ❌ 把测试 skip 掉让 pass 率好看（掩盖问题）

9. 与其他 skill 的关系

• dev-debug skill：开发循环里"实时看效果"用，是手测；本 skill 是自动化验证
• imagi-verify skill：验证 imagi 自身知识库一致性，与代码测试无关
• 互不重复