brainstorm

name	brainstorm
description	当用户面对模糊需求、需要澄清目标或约束、探索方案、评估可行性，或说“brainstorm”“头脑风暴”、 “先理清需求”“设计一下”“方案探讨”“先别写代码”“给几个方案选”时使用；实现前需要 共同决策时也使用。
metadata	{"openclaw":{"emoji":"💡"}}

brainstorm — 需求澄清与设计探索技能

执行前置

遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。

把想法/需求打磨成设计：先分类请求，再沿路径推进（理解上下文 → 澄清 → 设计方案 → 批准 → 交接），每类路径的批准闸门相同、产物规模不同。

核心原则

1. 先分类，再行动：动手前大声判定路径——spike（可行性问题，输出答案是结论）、 bounded（仓库内已有流程的小改动）、architectural（新项目/子系统/接口变更）； 无法确定时取更重的路径；棘轮单向：中途发现隐藏复杂度 → 升级路径并声明， 任务从不降级。
2. 批准闸门是硬门（HARD-GATE）：实现前必须先向用户说明意图并获批准； 简单任务简化的是设计产物（聊天里两句话），不是批准；"太简单不需要设计"正是 未检视假设导致返工最多的地方。
3. 一次问全：所有澄清问题在第一次交互一次性全部提出（编号列表，含目的/约束/成功标准）， 用户一次性回答，不逐次追问；优先选择题；未问全的问题不重复发问。
4. 方案给权衡：提出 2-3 个方案讲清取舍并给推荐（推荐放最前、说明理由）； YAGNI 冷酷执行——从每个方案与设计中删掉不必要的功能。
5. 分节展示：设计按复杂度缩放每节篇幅（直白处几句、微妙处 200-300 词）， 每节确认后再继续；覆盖架构/组件/数据流/错误处理/测试。
6. 隔离与清晰：拆成单一职责、接口清晰、可独立测试的小单元；文件变大是 职责过多的信号。
7. 尊重既有代码：先探索现状再提议，跟随既有模式；只提服务于当前目标的 改进，不做无关重构。
8. 终端状态绑定路径：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. 澄清（一次问全）

1. spike：呈现问题与探针计划（2-3 句），点头即继续；
2. bounded：把真正要紧的问题（目的/约束/成功标准）一次性全部列出， 用户一次回答，不逐次追问；
3. 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 获批了，后续改动也算获批"	每个任务独立分类、独立批准