القائمة
写完代码后协助测试 — 写测试用例 + 跑测试 + 失败帮修。触发场景：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 自身知识库一致性，与代码测试无关