القائمة
测试生成。基于 spec.md 或被测代码，生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | workflow-test-generation |
| description | 测试生成。基于 spec.md 或被测代码，生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。 |
根据调用上下文判断走哪条路径：
| 信号 | 路径 | 执行步骤 |
|---|---|---|
由 workflow-code-generation 完成后衔接进入，或用户明确提到需求管理链接 | 完整流程 | Step 1 → 2 → 3 → 4 → 5 |
| 用户直接说"给 X 写个测试"/"补个单测"，指定了具体代码 | 快速补测试 | Step 2 → 3 → 4 |
由 workflow-system-design 讨论测试计划章节时加载 | 测试策略设计 | Step 1 → 2 → 3，只输出计划，不生成代码 |
如果无法判断，默认走完整流程。
完整流程和测试策略设计执行本步骤。快速补测试跳过（用户已指定了被测代码）。
尝试读取 docs/design-docs/<module>/<feature>/spec.md：
有 spec.md：
无 spec.md（为已有代码补测试）：
根据代码特征自动判断需要哪些测试类型（可组合，非互斥），无法判断时才询问：
| 特征 | 测试类型 |
|---|---|
| 纯函数、无外部依赖 | 单元测试 |
| 端到端流程、多组件交互 | 集成测试 |
| spec.md 有性能指标要求 | 性能测试 |
一个 feature 通常需要多种测试类型组合，例如：核心逻辑用单元测试 + 端到端用集成测试。
分析被测代码，制定测试计划（不生成代码）：
创建测试任务清单，与用户确认后再继续：
示例：
1. [pending] UnitTest - FooClass::Bar() 正常路径 + 边界条件
2. [pending] UnitTest - FooClass::Bar() 异常处理
3. [pending] IntegrationTest - 端到端流程
测试策略设计路径到此结束。将测试计划输出为 spec.md 测试计划章节的内容，不进入 Step 4。
仅完整流程和快速补测试执行本步骤。
| 规范 | 何时加载 |
|---|---|
bp-coding-best-practices | 始终 |
std-cpp | .cc/.cpp/.h 文件 |
std-go | .go 文件 |
根据项目需要，额外加载其他编码规范 skill。
对每个测试任务生成测试代码。每个测试必须覆盖三类场景：
生成后更新构建配置，复用项目现有的测试基类和断言工具（不要自己造）。
每完成一个任务，标记 [completed]，继续下一个。
仅完整流程执行本步骤。
前置条件：所有测试用例已通过。
提示用户进入 workflow-code-review 进行 AI 代码评审（同时评审功能代码和测试代码）：
自测已全部通过。
推荐下一步：
- 说"CR"或"代码评审"进入 AI 代码评审阶段
代码文件修改的统一入口。当用户请求任何代码变更（新功能、优化、Bug 修复、重构）时必须首先调用此 skill。仅适用于代码文件（如 .cc/.cpp/.h/.go/.py 等），修改 .md 等非代码文件时不需要调用。它会评估复杂度、检查 spec.md、生成 tasks.md、并逐个任务执行。
将纠错经验沉淀为持久化的 Rules/Skills 更新，构建反馈闭环。当被用户纠正且错误具有模式性时自动触发，或通过 /reflect 命令手动触发回顾。
问题排查。当用户遇到编译错误、运行时异常、单测失败、流水线报错、现网告警等需要定位问题时触发。
代码评审。协调 5 个专项 reviewer subagent 对代码进行并行多维度审查。可由用户直接触发，也可由主 agent 加载后作为 Judge 执行。
需求澄清。只负责明确"要解决什么问题"，生成 spec.md 的前三章节（背景、目标、需求）。禁止在本阶段讨论设计方案——设计是 workflow-system-design skill 的职责。
系统设计。当 spec.md 前三章节（背景、目标、需求）已完整但设计章节为空时调用。按 spec.md 章节顺序逐个与用户讨论，每轮只处理一个 section。