Brainstorming

核心用法

Brainstorming 是一个前置设计技能，强制在执行任何创造性工作（功能开发、组件构建、行为修改）之前使用。它通过自然对话形式，分阶段将模糊想法转化为可落地的技术方案。

标准流程：
1. 理解意图 — 先检视项目现状（文件、文档、提交历史），然后逐题追问澄清需求，每次只问一个问题，优先使用选择题降低用户负担
2. 探索方案 — 提供 2-3 种可选路径，明确列出 trade-offs，并给出推荐选项及理由
3. 分段呈现设计 — 每 200-300 字输出一个模块（架构、组件、数据流、错误处理、测试），逐段确认后再继续
4. 文档固化 — 通过后将设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交 git；若继续开发，则创建隔离工作空间并生成详细实施计划

显著优点

• 强制深度思考："必须先用我"的机制杜绝了拍脑袋编码
• 增量验证：分段确认机制避免方向性错误累积到后期
• YAGNI 内建：明确要求从设计中剔除不必要的功能
• 上下文感知：主动检查项目现有状态，避免方案与现状脱节

局限性与风险

• 对话成本：简单改动可能显得流程过重
• 单线程瓶颈："一次一问"在紧急场景下可能显得拖沓
• 依赖用户配合：需要用户愿意投入时间回答追问，而非直接要代码
• 未覆盖安全扫描：认证报告显示未执行实际安全审计

适合人群

• 中大型功能开发的团队
• 需要降低架构决策返工率的场景
• 对"先设计后编码"有纪律要求的组织

常规风险

• 过度设计：虽有 YAGNI 原则，但实际效果依赖执行者的克制
• 文档债务：设计文档若不及时维护，可能与代码实现 divergence

核心用法

brainstorming 是一个纯文档型的协作式设计 Skill，用于在编码实施前系统性地探索用户需求、明确项目范围并产出可落地的技术方案。其工作流程分为三个阶段：

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

方案探索阶段：主动提供 2-3 种实现路径，附带权衡分析，明确推荐选项及理由，帮助决策者快速收敛。

设计呈现阶段：将方案拆解为 200-300 字的片段逐节输出，每节后确认方向正确性，覆盖架构、组件、数据流、错误处理和测试策略。验证通过后写入 docs/plans/YYYY-MM-DD-<topic>-design.md，并可衔接 superpowers:using-git-worktrees 和 superpowers:writing-plans 进入实施。

显著优点

• 认知友好：强制"一次一问"和"多选优先"原则，避免信息过载，显著提升协作效率
• YAGNI 原则：内建"如无必要，勿增实体"的约束，抑制功能蔓延
• 增量验证：分段确认机制降低返工成本，设计即文档直接落库
• 工具链衔接：与 git-worktrees、writing-plans 等 Skill 形成完整 DevOps 闭环

潜在局限

• 仅提供方法论框架，不直接生成代码或原型，重度依赖用户输入质量
• 对于技术栈选型、性能基准等深度技术问题，需结合其他专业 Skill
• 单次对话深度受限，复杂系统可能需要多轮迭代

适合人群

• 产品经理/技术负责人：快速对齐团队认知，输出可评审的设计文档
• 独立开发者：在动手编码前理清边界，避免中途推翻重来
• 开源贡献者：为 PR 提供清晰的设计依据和变更说明

常规风险

作为纯 Markdown 文档 Skill，无代码执行、无网络调用、无数据收集，天然免疫注入攻击与供应链风险。唯一需注意：设计文档的落地执行仍需人工把关，Skill 本身不保证方案的技术可行性，建议结合代码审查与测试验证。