菜单
写完代码后协助测试 — 写测试用例 + 跑测试 + 失败帮修。触发场景：plan-first 复杂任务（判据见 .claude/rules/im-agent-workflow.md 的任务复杂度分级表）的 plan 用户拍板后，必须主动询问"需要协助测试吗"。用户 yes 后由本 skill 编排 test-writer / test-runner / test-fixer 三个 SubAgent 完成测试闭环。简单任务（单文件改）不触发，避免噪音。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。Use when 用户说"新建数字人应用""开发智能体""做 XX 场景的 Demo""搭一个数字人""创建一个数字人项目"。
接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。
合并 master 前检查 swagger-repo.json 是否残留 feat 分支，半自动逐条切回并重跑 gen:api。**触发场景**：准备合并到 master 之前（由 git-ship skill 自动调用）/ 修改过 swagger-repo.json 的 branch 字段 / 拉到陌生分支后想确认 API 类型来源 / 用户输入 /check-api-branch。
多模型并行 Code Review。**自动触发场景**：用户拍板 plan 后改完代码（中等 / 复杂任务），AI 主动询问「需要 code review 吗？」**手动触发**：用户输入 `/code-review` 或说「review 一下这次改动 / 帮我看看这次提交」。按改动复杂度分级派 SubAgent，**轻量改动只派 1 个 sonnet 兜底，复杂任务才派 3 个含 opus 架构师**——不浪费最强模型在简单任务上。
公司前端通用编码规范（从 11 个项目 + 飞书知识库抽取）。当用户开始编写/修改前端 TS/TSX/Vue/SCSS 代码，或者需要 code review / 检查规范一致性时，**必须**加载本 skill 作为硬性规则基础。
启动开发环境 + 调试。触发场景："看一下效果 / 跑起来看看 / 启动一下 / 打开看看 / 启动 dev / 跑 dev"。本 skill 读 profile.devServer 配置 → 校验前置 → 后台 spawn dev server → 等 ready → 拼带 token 的真实域名 URL → open 浏览器。同时含项目特定的"关键调试场景"片段（按 profile 加载）。
| name | test-assist |
| description | 写完代码后协助测试 — 写测试用例 + 跑测试 + 失败帮修。触发场景：plan-first 复杂任务（判据见 .claude/rules/im-agent-workflow.md 的任务复杂度分级表）的 plan 用户拍板后，必须主动询问"需要协助测试吗"。用户 yes 后由本 skill 编排 test-writer / test-runner / test-fixer 三个 SubAgent 完成测试闭环。简单任务（单文件改）不触发，避免噪音。 |
把"写完代码"和"测试通过"主动闭环。本 skill 是编排器：决定测什么 / 派哪个 agent / 报告什么；不亲自写测试也不亲自跑。
.claude/rules/im-agent-workflow.md 的「任务复杂度分级」表）plan 拍板后用户改了代码，AI 必问一次：
「这个改动需要协助测试吗？我可以：
- 写一套测试用例（unit / component / e2e，按改动复杂度选）
- 跑测试 + 给报告
- 失败的我帮你修（最多 2 轮，仍失败报告你介入）
yes / 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 轮仍失败 → 上报用户介入
| 改动性质 | 测试类型 | 派 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。
| SubAgent | 职责 | 模型（默认） |
|---|---|---|
test-writer | 写 .spec.ts / .test.ts | sonnet（unit 时 main agent override 为 haiku） |
test-runner | 跑测试 + JSON 解析 + 总结 | haiku |
test-fixer | 失败分析 + 改代码 | sonnet |
test-runner 跑 → 失败
↓
第 1 轮：test-fixer 改 → test-runner 重跑 → 还失败？
↓
第 2 轮：test-fixer 改 → test-runner 重跑 → 还失败？
↓
**停下来报告用户**：「已尝试 2 次修复仍失败，错误：<spec:line + 一句>，建议你看一下」
为什么限 2 轮：防"AI 改错方向越改越乱"的无限修复循环。3 次没过 = 测试或代码方向有问题，需要人决策。
写 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。
参考 .ai/knowledge/ai-manual.md 第 5 节"SubAgent 模型选择"。要点：
默认 Sonnet，机械任务必须降到 Haiku。
测试全部跑完后写一份报告到 .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 句>」不要把整份报告复读。
dev-debug skill：开发循环里"实时看效果"用，是手测；本 skill 是自动化验证imagi-verify skill：验证 imagi 自身知识库一致性，与代码测试无关