workflow-brainstorm

将头脑风暴的想法转化为设计

目标

将“模糊的想法／需求”转化为可执行的设计和规格说明，并生成可复用的文件产物（而不只是停留在聊天中）。

关键要求：每次只问一个问题。如果主题复杂，就分多轮问答进行，不要一次抛出一整份清单。

核心流程（必须遵循）

0) 先检查项目上下文（存在代码仓库时必须执行）

提问前，快速检查：

• 关键文档：README.md、docs/、design-system.md（如果存在）
• 技术栈和限制：package.json / Cargo.toml / pyproject.toml 等
• 结构概览：顶层目录、主要模块
• 最近的更改：git log -n 10 --oneline（如果是 git 代码仓库）

输出一份非常简短的上下文摘要：说明观察到的情况和可能的限制（暂不开始设计）。

1) 理解想法（每次只问一个问题）

目标是收集最少量的信息（目的／限制／成功标准）。

规则：

• 每条消息只问 1 个问题
• 优先提供选择题（降低用户的认知负担），仅在必要时提出开放式问题
• 先询问决定方向的问题（目标／成功标准／非目标），再询问细节

2) 探索解决方案（2-3 个选项 + 权衡）

了解需求后：

• 提供 2-3 个选项（A/B/C）
• 说明每个选项的权衡（复杂度／风险／迭代速度／长期成本）
• 首先给出推荐选项，然后说明原因

3) 输出设计（每段 200-300 词，并逐段确认）

确信自己理解了需要完成的工作后，开始输出设计规格说明。

要求：

• 分段输出（每段约 200-300 词）
• 每段结尾都要询问用户确认，例如：“这样可以吗？”
• 设计至少应涵盖：
  • 架构和模块边界
  • 核心数据流（输入 → 处理 → 输出）
  • 错误处理和边界情况
  • 测试与验证策略（最低可行集合）

如果用户不同意某段内容：返回提问／选项阶段进行澄清，不要继续推进。

产物与持久化（强烈建议）

编写设计文档

优先写入运行目录（产物优先）：

• run_dir/evidence/YYYY-MM-DD-<topic>-design.md

如果没有 run_dir，但有 repo_root：

• 创建 runs/brainstorm/active/<run_id>/，并将设计文档写入 evidence/

注意：写入文件属于写操作；如果这是用户的项目代码仓库，写入前先确认“要我将内容保存到项目中吗？”

开始实施（可选）

设计确认后，提出一个问题，让用户选择下一步：

1. 直接开始实施（推荐 workflow-ship-faster 或 workflow-feature-shipper）
2. 先编写实施计划（将其作为检查清单项目保存到 run_dir/tasks.md，然后等待确认）
3. 需要先做研究／阅读代码（拆分到 run_dir/evidence/parallel/<task-name>/ 并行处理）

核心原则

• 每次只问一个问题：绝不要在一条消息中问 5 个问题
• 优先提供选择题：帮助用户更快、更有效地作答
• YAGNI：主动从设计中删去“目前不需要”的功能
• 增量验证：分段输出设计，并逐段确认