القائمة
系统设计。当 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 需要修改，告诉我具体哪个