用途
brainstorming-cn 用于在用户明确要求头脑风暴、收集需求、写 PRD，或探索「要不要做 / 做什么」时，通过协作对话将粗略想法转化为清晰的产品需求文档（PRD）。它不自动触发，仅在用户显式发起需求探索流程时才启动。其目标是产出一份完整、无歧义的 PRD，回答构建什么（WHAT）和为什么构建（WHY），而如何构建（HOW）留给后续阶段。
主要能力
- 探索项目上下文：检查文件、文档、最近的 commit，了解已有内容。
- 在主题涉及视觉问题时提供视觉伴侣（基于浏览器的伴侣工具，用于展示原型、图表和视觉选项），该提议必须是一条独立消息。
- 提出澄清问题：每次一个问题，了解目的、用户、约束、成功标准。
- 提出 2-3 种需求方案：不同的范围、功能优先级或用户流程方案，附带权衡分析和推荐。
- 分节展示需求：按复杂度分节，每节展示后获得用户批准。
- 编写 PRD：保存到 docs/prd/<topic>.md 并 commit。
- PRD 自检：内联检查占位符、矛盾、模糊性、范围、可测试性，发现问题直接修复。
- 用户审查关卡：请用户审查 PRD 文件，批准后才继续。
- 过渡到设计：调用 design 或实现规划技能，不调用任何实现技能。
使用方式
流程按检查清单顺序执行：探索项目上下文 → 判断是否有视觉相关问题（是则提供视觉伴侣，独立消息）→ 提出澄清问题 → 提出 2-3 种需求方案 → 分节展示需求 → 用户批准需求 → 编写 PRD → PRD 自检 → 用户审查 PRD → 调用 design/规划技能。
在理解想法阶段，先查看当前项目状态，评估范围；如果需求描述多个独立功能或用户旅程，立即指出并帮助分解为子项目，每个子项目有自己的 PRD。对于范围适当的项目，每次提一个问题，尽量使用选择题，每条消息只提一个问题，重点理解谁是用户、解决什么问题、成功是什么样、约束是什么。
在探索需求方案阶段，提出 2-3 种产品/功能层面的方案（非技术方案），例如不同范围级别（MVP vs 完整愿景 vs 分阶段推出）、不同用户流程或交互模型、不同功能优先级、不同目标用户或用例优先级，先展示推荐方案并解释原因。
在展示需求阶段，每个部分的篇幅与复杂度匹配，简单几句话，复杂的最多 200-300 字，每节展示后询问是否正确，涵盖问题陈述、目标用户、用户故事/用例、功能需求、非功能需求、验收标准、成功指标、不在范围内的事项。
PRD 结构应清楚回答：问题陈述、目标用户、用户故事/用例（用「作为[用户]，我希望[做什么]，以便[达成什么结果]」格式）、功能需求（具体且可测试）、非功能需求（性能、可访问性、安全、浏览器/设备支持）、验收标准（具体可验证）、成功指标、不在范围内。
PRD 之后：将验证通过的 PRD 写入 docs/prd/<topic>.md，如果可用使用 elements-of-style:writing-clearly-and-concisely 技能，commit 到 git；然后做 PRD 自检（占位符扫描、内部一致性、范围检查、模糊性检查、可测试性检查），发现问题内联修复；再请用户审查，等待回复，要求修改则修改并重新自检，批准后才继续；最后调用合适的 design 或实现规划技能，不要直接跳到编码。
适用场景
适用于用户显式发起需求探索、头脑风暴、收集需求、写 PRD 或探索「要不要做 / 做什么」的场景。每个项目都要经过这个流程，包括待办事项列表、单函数工具、配置变更等看似简单的项目；PRD 可以很简短，但必须写出来并获得批准。
限制
- 不自动触发，仅在用户显式发起需求探索流程时启动。
- 只关注 WHAT，绝不讨论 HOW，不涉及技术选型、架构、代码结构。
- 终止状态是调用 design 或实现规划技能，不要调用任何实现技能。
- 视觉伴侣是工具而非模式，接受伴侣不意味着每个问题都通过浏览器；使用浏览器展示本身是视觉的内容（原型、线框图、布局对比、用户流程图、并排功能对比），使用终端展示文字内容（需求问题、范围决策、用户故事讨论、验收标准、成功指标、优先级对话）。
- 视觉伴侣功能较新，可能消耗较多 token，需要打开一个本地 URL。
- 关于 UI 主题的问题不一定是视觉问题。
核心原则
每次一个问题；优先选择题；严格遵循 YAGNI，从所有需求中移除不必要的功能；只关注 WHAT；增量验证，分节展示需求并获得批准后再继续；保持灵活，有不明确的地方就回头澄清；明确不在范围内是优点，能有效防止范围蔓延。