brainstorm

头脑风暴

概述

使用此技能，通过结构化对话将粗略想法转化为清晰、便于评审的设计成果。

目标是：

1. 明确需求和约束
2. 探索各种方案及其权衡
3. 通过产出文档或移交规划，形成具体且经过验证的设计简报

工作流

步骤 1：收集项目背景

仅加载与当前想法相关的项目背景：

• 如果存在 docs/SUMMARY.md，先阅读。
• 仅加载与任务相关的详细文档。
• 优先查阅 Code Standard 文档，了解实现规范。
• 如果文档与代码或用户意图冲突，在进行大范围修改前，使用可用的交互式输入／提问工具。

同时检查与该想法相关的关键实现文件，并记录现有架构、依赖项和规范带来的约束。

本阶段应聚焦，只收集当前想法所需的信息。

步骤 2：明确需求

使用交互式输入／提问工具，依次提出有针对性的问题，消除歧义：

• 重点关注：
  • 目标和用户价值
  • 范围边界
  • 约束（技术、用户体验、性能、时间线）
  • 成功标准
  • 非目标

不要过早深入实现细节。

步骤 3：探索方案

提出 2-5 个可行方案。

每个方案都应包括：

• 简短概述
• 优点
• 缺点／风险
• 复杂度估算
• 推荐的适用条件

首先给出推荐方案，并说明它为何最符合项目背景和约束。

介绍完所有方案后，使用交互式输入／提问工具，让用户选择首选方案。列出概要选项。例如：

• 方案 A，简短概述
• 方案 B，简短概述
• 方案 C，简短概述
• 其他（请说明）

并为推荐方案添加标记，引导用户选择。

步骤 4：逐步呈现设计

用户选定方案后，分阶段呈现设计，并包含以下部分：

• 1. 基础 - 问题界定、目标和拟议的架构／流程。
• 2. 技术细节 - 数据模型、接口、错误处理、边缘情况和风险。
• 3. 交付 - 测试／验证策略和发布注意事项（如适用）。

呈现后，立即使用输入／提问工具询问是否要：

1. 继续下一步
2. 调整设计（需要输入文字）

步骤 5：收尾

在你和用户梳理完需求并验证设计后，确定后续行动。

使用输入／提问工具，向用户提供三个高层级的后续操作：

• "Write plan immediately" - 跳过产出文档步骤，直接移交 write-plan，并附上可视化内容。
• "Write artifacts" - 继续编写步骤 6 中所述的头脑风暴文档。
• "Implement immediately" - 如果设计清晰且风险较低，用户可以选择跳过文档和规划，直接进入实现阶段。
• "End session" - 停止；当前对话已提供足够的信息。

步骤 6（可选）：编写头脑风暴文档

仅在用户于步骤 5 明确选择 "Write artifacts" 后执行此步骤。

将结果保存到标准位置：

• 目录：docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/
• 主文件（必需）：docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/SUMMARY.md
• 可选的辅助文件：
  • docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/section-01-<slug>.md
  • docs/.brainstorms/YYMMDD-HHmm-<topic-slug>/section-02-<slug>.md
  • 等等

SUMMARY.md 格式：严格遵循 references/summary-template.md 中的模板。

草稿文档生成后，再次使用输入／提问工具，通过以下选项进行验证：

• "Write plan with current artifacts, context"
• "End session - artifacts are sufficient for now"
• "Need changes"（自由输入）- 收集反馈，修改文档，然后再次询问。

规则

• 在头脑风暴环节中，不要在此技能中编写生产代码或进行实现更改。
• 保持交互轻量且迭代进行；每个步骤都应在同一会话中完成。
• 不确定时，优先保证清晰，而非面面俱到；提出后续问题。
• 所有建议都应符合项目文档和标准。
• 明确说明所有假设；不要默默猜测。
• 编码前先思考： 明确指出假设。如果存在多种解释，应一一列出，不要擅自选择。如果有更简单的方法，应说明，并在适当时提出异议。
• 所有产物都应使用与当前会话相同的语言。