Brainstorming

核心用法

Brainstorming 是一个前置性设计技能，强制用于任何创造性工作（功能开发、组件构建、功能添加或行为修改）。它通过自然对话形式，将模糊的想法转化为完整的设计规范。

执行流程分为四个阶段：

1. 理解阶段：首先检查项目当前状态（文件、文档、最近提交），然后通过一次一个问题的方式逐步澄清需求。优先使用选择题降低用户认知负担，聚焦目标、约束条件和成功标准。

2. 探索阶段：主动提出 2-3 种不同方案并分析利弊，明确给出推荐选项及理由。

3. 设计呈现阶段：将设计方案拆分为 200-300 字的小节逐段展示，每段后征求确认。覆盖架构、组件、数据流、错误处理和测试等维度。

4. 后续动作：验证通过后将设计文档写入 docs/plans/，并可配合 superpowers:using-git-worktrees 和 superpowers:writing-plans 进入实现阶段。

显著优点

• 防止过早实现：强制设计先于编码，减少返工
• 降低认知负荷："一次一问"原则避免信息过载
• 增量验证机制：分小节确认确保方向正确
• 内置最佳实践：YAGNI 原则、多方案对比、完整文档化
• 工具链集成：与 Git worktrees、计划编写技能无缝衔接

潜在局限

• 对话成本：简单变更可能显得流程冗长
• 同步依赖：需要用户持续交互，不适合异步批处理
• 上下文窗口消耗：长项目历史检查可能占用大量 tokens
• 无自动决策：过度依赖用户确认可能延缓进度

适合人群

• 需要系统化设计流程的中大型项目开发者
• 希望减少"需求理解偏差"的团队
• 追求代码可维护性的技术负责人

常规风险

• 流程僵化：若对所有变更严格执行可能降低效率，建议根据变更复杂度灵活调整
• 文档债务：生成的设计文档若未及时同步更新，易与实际代码脱节

核心用法

该 Skill 是一套结构化设计协作框架，适用于任何创意工作启动前的需求澄清阶段。用户提出初步想法后，AI 会以"一次一问"的克制节奏逐步探索：先核查项目上下文（文件、文档、提交历史），再通过选择题或开放式问题 refine 需求，最终输出完整设计文档。

关键流程三步走：
1. 理解意图 — 单线程提问聚焦目的、约束与成功标准
2. 探索方案 — 强制提供 2-3 种带 trade-off 的选项，并给出推荐及理由
3. 增量呈现 — 设计稿按 200-300 词分段输出，每段确认后再推进，覆盖架构、组件、数据流、错误处理、测试

显著优点

• 防过度设计：YAGNI（You Aren't Gonna Need It）原则内建，自动剔除冗余功能
• 认知负荷低：单问题交互避免信息过载，多选题降低用户决策成本
• 可追溯交付：设计定稿后自动写入 docs/plans/ 并提交 Git，形成设计资产
• 工具链集成：与 using-git-worktrees、writing-plans 等 Skill 无缝衔接

潜在局限

• 重度依赖用户参与：若用户无法持续反馈，流程将阻塞在问答阶段
• 非即时代码生成：追求严谨而非速度，不适合需要快速原型的场景
• T3 来源可信度：维护者为个人开发者 tazio7，无组织背书，版本更新与长期维护存在不确定性

适合人群

• 独立开发者启动新功能前的需求梳理
• 技术团队进行方案评审前的结构化准备
• 开源项目贡献者撰写 RFC/提案前的构思阶段

常规风险

| 风险类型 | 评估 | 说明 |

|---------|------|------|

| 代码执行 | 无 | 纯 Markdown 文档，无可执行代码 |

| 数据泄露 | 无 | 零外部 API 调用，无网络请求 |

| 隐私合规 | 低风险 | 不收集敏感数据，符合 GDPR/CCPA |

| 设计偏差 | 中风险 | 依赖 AI 对业务场景的理解深度，关键决策仍需人工复核 |

建议：用于探索性设计而非最终决策，复杂项目需配合领域专家复核。