用途：在使用者只有模糊想法或需求时，把其转化为可落地的设计与规格，并产出可复用的文件产物，而不只是停留在对话中。适用于新功能、新组件或行为变更的实现前阶段。
主要能力与流程：
- 先检查项目上下文：在仓库存在时为必做步骤，快速查看 README.md、docs/、design-system.md（如存在）、依赖清单（package.json / Cargo.toml / pyproject.toml 等）、顶层目录与主要模块，以及 git log -n 10 --oneline（若为 git 仓库）。输出简短的上下文摘要，指出观察结果与可能的约束点，但暂不开始设计。
- 理解想法：一次只问一个问题，优先用多选题降低认知负担，必要时才用开放题；先问目标、成功标准和“非目标”等方向性问题，再问细节。
- 探索方案：给出 2-3 个方案（A/B/C），说明复杂度、风险、迭代速度和长期成本等权衡，先给出推荐项再解释理由。
- 输出设计：每段约 200-300 字，段末请用户确认；设计至少覆盖架构与模块边界、核心数据流（输入→处理→输出）、错误处理与边界情况、测试与验证策略（最小可行集）。用户不同意某段时，回到提问或方案阶段澄清。
产物与持久化：优先写入 run 目录，例如 run_dir/evidence/YYYY-MM-DD-<topic>-design.md；若无 run_dir 但有 repo_root，则创建 runs/brainstorm/active/<run_id>/ 并写入 evidence/。写文件属写操作，若目标是用户项目仓库，需先确认是否持久化到项目。设计确认后可询问下一步：直接实现（推荐 workflow-ship-faster 或 workflow-feature-shipper）、先写实现计划（持久化为 run_dir/tasks.md 清单后等待确认），或先做研究/读代码（拆分到 run_dir/evidence/parallel/<task-name>/ 并行执行）。
关键原则：一次只问一个问题，不在一封信里抛出 5 个问题；优先多选题；用 YAGNI 主动剔除“暂不需要”的功能；分段增量验证，每段都确认。限制：资料未提供具体价格、平台或效果数据；该技能依赖人工确认推进。