菜单
系统设计。当 spec.md 前三章节（背景、目标、需求）已完整但设计章节为空时调用。按 spec.md 章节顺序逐个与用户讨论，每轮只处理一个 section。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
代码文件修改的统一入口。当用户请求任何代码变更（新功能、优化、Bug 修复、重构）时必须首先调用此 skill。仅适用于代码文件（如 .cc/.cpp/.h/.go/.py 等），修改 .md 等非代码文件时不需要调用。它会评估复杂度、检查 spec.md、生成 tasks.md、并逐个任务执行。
测试生成。基于 spec.md 或被测代码，生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。
将纠错经验沉淀为持久化的 Rules/Skills 更新，构建反馈闭环。当被用户纠正且错误具有模式性时自动触发，或通过 /reflect 命令手动触发回顾。
问题排查。当用户遇到编译错误、运行时异常、单测失败、流水线报错、现网告警等需要定位问题时触发。
代码评审。协调 5 个专项 reviewer subagent 对代码进行并行多维度审查。可由用户直接触发，也可由主 agent 加载后作为 Judge 执行。
需求澄清。只负责明确"要解决什么问题"，生成 spec.md 的前三章节（背景、目标、需求）。禁止在本阶段讨论设计方案——设计是 workflow-system-design skill 的职责。
| name | workflow-system-design |
| description | 系统设计。当 spec.md 前三章节（背景、目标、需求）已完整但设计章节为空时调用。按 spec.md 章节顺序逐个与用户讨论，每轮只处理一个 section。 |
AI 负责调研代码背景，用户主导设计决策。
| AI 自己调研（读代码） | 与用户讨论 |
|---|---|
| 现有模块结构和职责 | 设计方向和权衡取舍 |
| 已有接口和数据结构 | 接口变更决策 |
| 依赖关系和调用链 | 模块划分决策 |
| 技术约束（框架、协议） | 性能/可维护性权衡 |
规则：如果信息可以从 codebase 获取，AI 必须自己调研，不问用户。
AI 通过提问帮助用户发现问题和权衡：
| 场景 | AI 行为 |
|---|---|
| 用户正在思考/描述设计 | 只提问和质疑，不给方案 |
| 用户明确请求帮助 | 先追问确认理解 → 加载规范 → 生成建议 → 询问意见 |
| 用户卡住（多轮无进展） | 提供思考方向，仍以问题形式呈现 |
| 第 6 节业界调研 | AI 主动搜索并提供业界方案作为参考 |
spec.md 已存在且第 1-3 节（背景、目标、需求）完整workflow-requirements-clarification Skillworkflow-requirements-clarification 完成后用户确认进入设计阶段在讨论到相关 section 时才加载对应规范，不要在开始时一次性加载所有规范：
| 规范 | 何时加载 |
|---|---|
bp-architecture-design Skill | 讨论 4.1 方案概览时加载 |
bp-component-design Skill | 讨论 4.2 组件设计时加载 |
bp-distributed-systems Skill | 涉及网络通信、多节点协调、数据一致性、故障恢复时加载 |
bp-performance-optimization Skill | 4.3 核心逻辑完成后加载，优化性能方面的设计考量 |
workflow-test-generation Skill | 讨论 7. 测试计划时加载 |
| AI 应该做 | AI 不应该做 |
|---|---|
| 提供思考框架和维度 | 未经请求就给设计方案 |
| 质疑设计的合理性 | 未追问清楚就生成内容 |
| 指出潜在风险和权衡 | 跳过追问直接给设计 |
| 用户请求时生成设计建议 | 生成后不询问用户意见 |
1. 说明当前 section 和目标
2. 提供思考框架（要考虑哪些维度）
3. 请用户描述设计想法
4. 等待用户回答
5. 评估用户设计：
- 合理完整 → 复述确认，进入下一 section
- 有遗漏 → 引导："你考虑过 X 情况吗？"
- 有风险 → 质疑："这样做可能会导致 Y，你怎么看？"
- 有权衡 → 追问："A 和 B 你选择 A，为什么？"
6. 用户完善后，复述确认，更新 spec.md
提供思考框架（不是给答案）：
AI："设计架构时，通常需要考虑：
- 模块如何划分？职责边界在哪？
- 模块之间的依赖关系是什么？
- 数据流是怎样的？
请描述一下你的整体设计思路。"
质疑潜在风险：
用户："我打算用单例模式"
AI："单例在多线程环境下可能有问题。这个模块会被多线程访问吗？"
用户："4.1 方案概览我不太有思路，你能给我一些建议吗？"
AI：（先追问）
"好的。在给你建议之前，我想先确认几点：
- 这个功能是新增模块，还是在现有模块上扩展？
- 对改动范围有限制吗？
- 性能是关键考量吗？"
用户："在现有模块扩展，尽量不改核心路径，性能很重要"
AI：（加载规范，生成建议）
"基于你的约束，我有几个方向供你参考：
**方向 1：Plugin 模式**
- 优点：不改核心路径，隔离性好
- 缺点：可能有间接调用开销
**方向 2：条件分支**
- 优点：简单直接
- 缺点：会修改现有代码路径
你倾向于哪个方向？或者有其他想法？"
目标：理解现有实现 + 确认对需求的理解
AI 操作：
codebase-researcher subagent 深度调研相关代码（模块结构、接口、依赖链、技术约束）向用户汇报（必须）：
我已读完 spec.md 并调研了相关代码：
**需求理解**：
- 问题：[复述 spec.md 中的问题]
- 目标：[复述目标]
- 关键约束：[复述非功能需求]
**代码调研**：
- 相关模块：[列出发现的模块]
- 现有接口：[列出相关接口]
- 技术约束：[发现的约束]
请确认我的理解是否正确？有遗漏或错误的地方吗？
结束条件：用户确认理解正确。必须等用户确认后才能进入设计讨论。
好的，我们现在进入 **系统设计** 阶段，从 **4.1 方案概览** 开始。
请描述一下你的整体设计思路。
每轮只讨论一个 section。详细的 section 引导模式参见 reference/section-guide.md。
判断 section 是否适用：
AI："4.2.3 数据模型这个 section，你的需求涉及新的数据结构吗？不涉及可以跳过。"
用户跳过时，在 spec.md 标注 N/A - 本需求不适用。
每个 section 完成后：
| ❌ 错误做法 | ✅ 正确做法 |
|---|---|
| 问用户"现有实现是怎样的" | AI 自己读代码调研 |
| 直接开始设计讨论 | 先展示需求摘要 + 代码调研，确认后再开始 |
| 用户没请求就给方案 | 先提问，等用户请求帮助再给建议 |
| 生成设计后当作最终方案 | 询问"你倾向于哪个方向？" |
| 用户说什么就同意什么 | 质疑潜在问题 |
| 4.1 讨论中写入具体调用点/函数签名 | 记录备忘，进入 4.3 时再写入 |
| 4.1 未完成就开始写 4.2/4.3 | 严格按 4.1 → 4.2 → 4.3 顺序逐级完成 |
spec.md 设计部分已完成。
你可以：
- 说"开始编码"进入 code generation 阶段
- 说"先写测试"进入 TDD 模式
- 如果某个 section 需要修改，告诉我具体哪个