用途：在实现之前，把模糊想法或需求转成可执行的设计与规格，并产出可复用的文件产物，而不只是停留在对话里。适用于新功能、新组件或行为变更。
主要能力与流程：
- 先检查项目上下文：若存在代码库，先快速查看 README.md、docs/、design-system.md，技术栈与约束（package.json / Cargo.toml / pyproject.toml 等），顶层目录与主要模块，以及 git log -n 10 --oneline；随后给出简短上下文总结，不急于设计。
- 理解想法：每次只问一个问题，优先选择题式提问，先问目标、成功标准与非目标，再问细节。
- 探索方案：给出 2-3 个方案（A/B/C），说明复杂度、风险、迭代速度与长期成本等取舍，先给推荐项并解释原因。
- 输出设计：按约 200-300 字分段输出，每段末尾请求确认，例如“Does this look good?”；设计至少覆盖架构与模块边界、核心数据流、错误处理与边界情况、测试与验证策略的最小可行集。用户不认可某段时，回到提问或方案阶段澄清，不强行推进。
用法与产物：强烈建议写设计文档，优先写入 run_dir/evidence/YYYY-MM-DD-<topic>-design.md；若没有 run_dir 但有 repo_root，则创建 runs/brainstorm/active/<run_id>/，并写入 evidence/。写文件属于写操作，若是用户项目仓库，写入前先确认“should I persist to the project?”。设计确认后，可再问一个问题让用户选择下一步：直接进入实现（推荐 workflow-ship-faster 或 workflow-feature-shipper）、先写实现计划（持久化为 run_dir/tasks.md 清单后等待确认），或先做研究/代码阅读（拆分到 run_dir/evidence/parallel/<task-name>/ 并行进行）。
限制与原则：每次只问一个问题，不要一次性抛出五个问题；优先选择题；遵循 YAGNI，主动移除“暂不需要”的功能；分段增量验证。其他细节暂未提供。