Brainstorm（启发式，非流水线）

把模糊想法变成可评审的短设计。本 skill 不进入 spec/research-workflow.yaml，也不阻断 gate / reducer。

何时用 / 何时跳过

默认姿态：建议 → 征求同意 → 再展开。不要未经提示就开长篇 brainstorm。

融合原则（来源）

轻量流程（可中途退出）

0. 征得同意（一句）→ 1. 扫项目上下文 → 2. 澄清（一次一问）
→ 3. 2–3 方案取舍 → 4. 短设计确认 → 5. 可选落盘 → 6. 交接下一 skill

任一步用户说「够了 / 直接做」→ 立即结束 brainstorm，进入实现或 research。

Step 0：征得同意

示例：

这块看起来还没对齐意图/方案。要不要先快速 brainstorm（几轮澄清 + 方案对比）？也可以直接做。

Step 1：项目上下文

• 读相关文件、docs、近期结构；跟随现有模式
• 请求过大（多个独立子系统）→ 先拆分，再对第一块 brainstorm
• 不跑无关重构

Step 2：澄清

• 一次一问；能多选就多选
• 聚焦：目的、约束、成功标准、非目标
• 不要一次抛出问卷

Step 3：方案取舍

• 给出 2–3 个可行路径
• 每项：要点、代价、适用场景
• 先写推荐项 + 理由（不要假中立堆砌）

Step 4：短设计

按复杂度缩放：琐碎几句；复杂则分节（架构 / 组件 / 数据流 / 错误与测试），每节可问「这样可以吗」。

设计时检查：

• 单元是否单一职责、接口是否清晰
• 能否在不读内部的情况下理解用途
• 是否违反 YAGNI

Step 5：可选落盘

用户需要可追溯文档时写入：

• 产品/架构向：docs/design/YYYY-MM-DD-<topic>-brainstorm.md（或交给 write-idea-docs 升格为 *-architecture.md）
• 研究向：把结论摘要并入 .research/<run-id>/artifacts/research-brief.json 的 scope / evidenceTargets 草稿

落盘后快速自检：无 TBD、无自相矛盾、范围可执行、歧义已拍板。

Step 6：交接（非强制链）

不要把 brainstorm 当成必须接到 writing-plans / deep-research 的硬终端态。

与硬流水线的边界

• 不新增 Spec state、gate、reducer 事件
• 不在 stop hook 里强制跑 brainstorm
• 不因「太简单」以外的原因默认拦截所有编码（与 Superpowers HARD-GATE 不同：此处为启发式）
• Visual companion / 浏览器 mockup：可选；无本地 companion 服务时用 Mermaid / 文字对比即可（draw-mermaid-diagrams）

产出检查（若落盘）

见 references/heuristic-checklist.md。