| name | brainstorm |
| description | 当用户面对模糊需求、需要澄清目标或约束、探索方案、评估可行性，或说“brainstorm”“头脑风暴”、
“先理清需求”“设计一下”“方案探讨”“先别写代码”“给几个方案选”时使用；实现前需要
共同决策时也使用。
|
| metadata | {"openclaw":{"emoji":"💡"}} |
brainstorm — 需求澄清与设计探索技能
执行前置
遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。
把想法/需求打磨成设计：先分类请求，再沿路径推进（理解上下文 → 澄清 → 设计方案 →
批准 → 交接），每类路径的批准闸门相同、产物规模不同。
核心原则
- 先分类，再行动：动手前大声判定路径——spike（可行性问题，输出答案是结论）、
bounded（仓库内已有流程的小改动）、architectural（新项目/子系统/接口变更）；
无法确定时取更重的路径；棘轮单向：中途发现隐藏复杂度 → 升级路径并声明，
任务从不降级。
- 批准闸门是硬门（HARD-GATE）：实现前必须先向用户说明意图并获批准；
简单任务简化的是设计产物（聊天里两句话），不是批准；"太简单不需要设计"正是
未检视假设导致返工最多的地方。
- 一次问全：所有澄清问题在第一次交互一次性全部提出（编号列表，含目的/约束/成功标准），
用户一次性回答，不逐次追问；优先选择题；未问全的问题不重复发问。
- 方案给权衡：提出 2-3 个方案讲清取舍并给推荐（推荐放最前、说明理由）；
YAGNI 冷酷执行——从每个方案与设计中删掉不必要的功能。
- 分节展示：设计按复杂度缩放每节篇幅（直白处几句、微妙处 200-300 词），
每节确认后再继续；覆盖架构/组件/数据流/错误处理/测试。
- 隔离与清晰：拆成单一职责、接口清晰、可独立测试的小单元；文件变大是
职责过多的信号。
- 尊重既有代码：先探索现状再提议，跟随既有模式；只提服务于当前目标的
改进，不做无关重构。
- 终端状态绑定路径：architectural 之后只转 plan（不接其他实现技能）；
bounded 批准后直接走正常开发流程（TDD 适用），无计划文档；spike 终端是
一份建议报告（产物标注一次性）。
触发时机
- 用户要求澄清设计："brainstorm"、"头脑风暴"、"先理清需求"、"设计一下"、
"方案探讨"、"需求不清楚"、"先想清楚再动手"
- 用户要求方案选择："给几个方案"、"哪个方案好"、"可行性评估"、"能不能做"
- 用户给出模糊生成请求："做个xxx"（细节不明）、"实现一个工具"（范围未定）
- 与其他技能配合：architectural 路径产出设计后转 plan；bounded 批准后直接实现
（TDD 适用）；实现计划执行用 make；实现报错用 debug；需求已明确时跳过本技能
工作流程
Step 1. 路径分类（先宣布）
读取上下文（文件/文档/近期提交）后判定路径并向用户宣布（可被推翻）：
| 路径 | 判定条件 | 产物 | 终端 |
|---|
| spike | 可行性问题（"能不能…"），输出是答案不是代码 | 2-3 句问题+探针计划 | 建议报告（构建物标注一次性） |
| bounded | 仓库内已有流程的小改动（新 flag/小接口/单文件修复） | 聊天内短设计 | 批准后直接实现 |
| architectural | 新项目/子系统/重构组件关系/改他人依赖的接口 | 分节设计 + 设计文档 | 批准后转 plan |
- 中途发现隐藏复杂度 → 升级路径，停下告知用户，不蒙混过关；
- 多独立子系统的大请求 → 先帮助拆解为子项目（各自 spec→plan→实现循环），
再对第一个子项目走设计流程。
Step 2. 澄清（一次问全）
- spike：呈现问题与探针计划（2-3 句），点头即继续；
- bounded：把真正要紧的问题（目的/约束/成功标准）一次性全部列出，
用户一次回答，不逐次追问；
- architectural：先一次性列出目的/约束/成功标准问题，用户回答后再给
2-3 个方案（权衡 + 推荐）。
Step 3. 设计方案
- bounded：聊天内呈现短设计（方法/涉及文件/测试），停下等明确批准——
边展示边开始实现就是跳过闸门；
- architectural：按复杂度分节呈现（每节后确认），覆盖架构/组件/数据流/错误
处理/测试；设计遵循「隔离与清晰」与「尊重既有代码」原则。
Step 4. 批准与交接
- 批准 = 用户明确同意；未批准不实现；
- spike：调查并报告建议（结论），构建物标注"一次性";
- bounded：批准后直接实现（按正常开发流程，TDD 适用）；
- architectural：写设计文档（如
docs/plans/YYYY-MM-DD-<topic>-design.md），
自审（占位符/内部矛盾/范围/歧义四项），请用户审阅，批准后转 plan 技能
写实现计划——不接其他技能。
Step 5. 总结（结构化输出）
✓ brainstorm 完成
请求: <请求描述>
路径: <spike/bounded/architectural>（中途升级: <原因>，无则省略）
澄清: <N 个问题>
设计: <分节设计要点；bounded 聊天内 / architectural 设计文档路径>
批准: <获准/被否/修订，时间>
交接: <plan 技能 / 直接实现（TDD）/ 建议报告>
遗留: <未决问题/待用户确认项，无则省略>
错误处理
| 场景 | 处理 |
|---|
| 请求分类模糊 | 取更重路径（棘轮单向），并告知用户 |
| 用户要求跳过设计直接实现 | 仍呈现最短设计（两句话）并获批准——批准闸门不过场 |
| 设计中途发现复杂度超预期 | 停止，升级路径，向用户声明后继续 |
| 用户否决方案 | 询问修改点，修订后重新展示，不擅自开始实现 |
| 请求含多个独立子系统 | 先拆解子项目，逐个走设计流程 |
| 用户未批准即催促实现 | 重申批准闸门原则，呈现设计等待明确同意 |
| 与已有技能职责重叠（如需求已明确） | 需求明确时直接转对应技能，注明无需本技能 |
注意事项
- 批准闸门是所有路径的硬门：展示设计并在同一口气里开始实现 = 跳过闸门；
- 简单任务缩短设计、不缩短批准；"太简单"是最危险的自欺理由（见红旗表）；
- 不越界访问工作目录之外的内容；
- 不删除文件（用户未明确要求时）；本次改动按公共 Git 契约检查，不自动暂存、提交或推送；
红旗表（出现即停下自检）
| 想法 | 现实 |
|---|
| "这个太简单，不需要设计" | 简单 = 短设计，不是无设计；聊天里两句话然后批准 |
| "我标成 bounded 跳过规格" | 伸手去摘"跳过工作的标签"本身就是怀疑——取更重路径 |
| "设计显而易见，边读边开始" | 闸门是批准，不是设计长度；展示后停到听见"可以" |
| "我懂这类应用，所以是 bounded" | bounded 度量仓库现状，不是你的熟悉度；新项目没有既有流程 = architectural |
| "spike 跑通了，代码留着" | spike 输出是答案；留下代码是新请求，重新分类 |
| "变大了，但快完了——不用重新分类" | 隐藏复杂度中途升级路径；停下说明 |
| "spike 获批了，后续改动也算获批" | 每个任务独立分类、独立批准 |
