用途
brainstorming 是一个在开始任何创意或实现工作之前使用的技能，目标是通过自然的协作式对话，把模糊的想法逐步转化为完整的设计与规格说明（spec）。它强调：在任何实现之前，必须先探索用户意图、需求与设计。
该技能源自 obra/superpowers 的 skills/brainstorming，由 acaprino/daodan 移植。
主要能力
- 先了解当前项目上下文（文件、文档、最近的提交）。
- 一次只问一个澄清问题，聚焦目的、约束与成功标准。
- 提出 2-3 种不同方案，说明取舍并给出推荐。
- 分段呈现设计，每段后询问用户是否认可。
- 将验证过的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交到 git。
- 对规格进行自审：检查占位符、内部一致性、范围、歧义，并就地修复。
- 请用户审阅书面规格，获得批准后再进入下一步。
- 最后调用 writing-plans 技能生成实现计划。
使用方式
该技能以清单（checklist）方式组织，要求为每一项创建任务并按顺序完成：
- 探索项目上下文——检查文件、文档、最近的提交。
- 提供可视化伴侣（如果话题会涉及视觉问题）——此消息必须单独发送，不能与澄清问题合并。
- 提出澄清问题——一次一个，理解目的/约束/成功标准。
- 提出 2-3 种方案——附带取舍与推荐。
- 呈现设计——按复杂度分段，每段后获得用户批准。
- 编写设计文档——保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交。
- 规格自审——快速内联检查占位符、矛盾、歧义、范围。
- 用户审阅书面规格——在继续之前请用户审阅规格文件。
- 过渡到实现——调用 writing-plans 技能创建实现计划。
流程的终态是调用 writing-plans。不要直接调用任何实现类技能（frontend、python-tdd、tauri 等）。brainstorming 之后唯一要调用的技能是 writing-plans。
理解想法
- 先查看当前项目状态（文件、文档、最近的提交）。
- 在问细节问题之前先评估范围：如果请求描述了多个独立子系统（例如“构建一个包含聊天、文件存储、计费和数据分析的平台”），应立即指出。不要花问题去细化一个需要先分解的项目。
- 如果项目对单个规格来说太大，帮助用户分解为子项目：哪些是独立部分、它们如何关联、应按什么顺序构建。然后按正常设计流程对第一个子项目进行头脑风暴。每个子项目都有自己的 spec -> plan -> implementation 循环。
- 对范围合适的项目，一次问一个问题来细化想法。
- 尽可能优先使用多选题，开放式问题也可以。
- 每条消息只问一个问题——如果某个话题需要更多探索，拆成多个问题。
- 聚焦理解：目的、约束、成功标准。
探索方案
- 提出 2-3 种不同方案并说明取舍。
- 以对话方式呈现选项，附上你的推荐与理由。
- 先给出推荐选项并解释原因。
呈现设计
- 当你确信理解了要构建的内容后，呈现设计。
- 每段的篇幅按复杂度缩放：简单则几句话，复杂则最多 200-300 字。
- 每段后询问目前看起来是否正确。
- 覆盖：架构、组件、数据流、错误处理、测试。
- 如果有地方说不通，随时准备回头澄清。
为隔离与清晰而设计
- 把系统拆成更小的单元，每个单元有单一明确目的，通过定义良好的接口通信，可被独立理解和测试。
- 对每个单元，应能回答：它做什么、如何使用、依赖什么？
- 别人能否不读内部实现就理解一个单元做什么？能否在不破坏使用方的情况下修改内部实现？如果不能，边界就需要改进。
- 更小、边界清晰的单元也更便于处理——你能更好地推理一次能放进上下文的代码，文件聚焦时编辑也更可靠。文件变大往往意味着它做得太多。
在现有代码库中工作
- 在提出改动前先探索当前结构，遵循现有模式。
- 如果现有代码的问题影响本次工作（例如文件过大、边界不清、职责纠缠），把有针对性的改进纳入设计——就像好开发者会改进自己正在处理的代码。
- 不要提出无关的重构，聚焦于服务当前目标的内容。
设计之后
文档：
- 将验证过的设计（spec）写入 docs/plans/YYYY-MM-DD-<topic>-design.md。
- （用户对 spec 位置的偏好可覆盖此默认值。）
- 将设计文档提交到 git。
规格自审：写完 spec 文档后，用全新的眼光审视它：
- 占位符扫描：是否有“TBD”“TODO”、不完整章节或模糊需求？修复它们。
- 内部一致性：各章节是否互相矛盾？架构是否与功能描述一致？
- 范围检查：是否足够聚焦于单个实现计划，还是需要分解？
- 歧义检查：是否有需求可被两种方式解读？如果有，选定一种并明确写出。
- 就地修复任何问题。无需重新审阅——修复后继续即可。
用户审阅关卡：spec 审阅通过后，在继续之前请用户审阅书面 spec：
“Spec written and committed to <path>. Please review it and let me know if you want to make any changes before we start writing out the implementation plan.”
等待用户回复。如果他们要求修改，就修改并重新运行 spec 自审。只有用户批准后才继续。
实现：
- 调用 writing-plans 技能创建详细的实现计划。
- 不要调用任何其他技能。writing-plans 是下一步。
关键原则
- 一次一个问题——不要用多个问题压垮用户。
- 优先多选题——可能时比开放式问题更容易回答。
- 无情地 YAGNI——从所有设计中移除不必要的功能。
- 探索替代方案——在定稿前总是提出 2-3 种方案。
- 增量验证——呈现设计，获得批准后再继续。
- 保持灵活——当有地方说不通时回头澄清。
可视化伴侣
可视化伴侣是一个基于浏览器的辅助工具，用于在头脑风暴期间展示模型图、图表和视觉选项。它作为工具提供，而非一种模式。接受该伴侣意味着它可用于那些受益于视觉呈现的问题；并不意味着每个问题都走浏览器。
注意：可视化伴侣需要来自 obra/superpowers 的上游 scripts/ 目录。完整指南见 references/visual-companion.md。
提供伴侣：当你预判即将到来的问题会涉及视觉内容（模型图、布局、图表）时，一次性征求同意：
“Some of what we're working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and can be token-intensive. Want to try it? (Requires opening a local URL)”
此提议必须单独成一条消息。不要与澄清问题、上下文摘要或任何其他内容合并。该消息应只包含上述提议，不含其他内容。等待用户回复后再继续。如果他们拒绝，则继续纯文本头脑风暴。
逐问题决策：即使用户接受，也要对每个问题单独决定用浏览器还是终端。判断标准：用户看到它是否比读到它更容易理解？
- 对本身是视觉的内容使用浏览器——模型图、线框图、布局对比、架构图、并排视觉设计。
- 对文本内容使用终端——需求问题、概念选择、取舍列表、A/B/C/D 文本选项、范围决策。
- 关于 UI 话题的问题不自动是视觉问题。“在这个语境中 personality 是什么意思？”是概念问题——用终端。“哪种向导布局更好？”是视觉问题——用浏览器。
如果他们同意使用伴侣，在继续之前阅读 references/visual-companion.md 获取详细指南。
适用场景
适用于任何创意或实现工作开始之前，包括待办清单、单函数工具、配置变更等各类项目。尤其适合需要把模糊想法转化为明确设计与规格、并希望在动手前获得用户逐段确认的场景。
限制
- 该技能本身不直接进行实现，终态是调用 writing-plans 技能。
- 可视化伴侣需要来自 obra/superpowers 的上游 scripts/ 目录，且仍属新功能，可能消耗较多 token，需要打开本地 URL。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。