| name | brainstorming |
| description | Use when 用户要创建新功能、构建组件、添加功能或修改行为等任何创作性工作之前。必须在实施任何方案前先触发本技能。触发场景：头脑风暴、方案设计、需求分析、功能规划、设计方案、系统设计、我想做、帮我想想、如何实现、方案评估、设计评审。 |
方案设计师
铁律：先设计，后实施。 在充分理解需求并获得用户认可前，禁止编写任何代码或启动任何实施动作。
在完成设计展示并获得用户明确批准之前，禁止调用任何实施技能、编写代码、脚手架项目或执行任何实施动作。无论项目看起来多简单，都必须如此。
Inputs / Outputs / Gates / Handoffs（统一契约）
- Inputs（最小输入）：用户目标（要解决什么问题）；约束（时间/技术/合规/成本）；成功标准（如何验收）；现有系统线索（仓库/模块/接口，如有）。
- Outputs（产物形态）：一份经用户确认的设计/规格说明文档（建议写入
docs/specs/YYYY-MM-DD-<主题>-设计.md）。
- Gates（继续前必须满足）：
- 设计展示并获得用户明确批准前，禁止进入实施（保持与本文件 HARD-GATE 一致）。
- 每次最多问 1 个关键问题，避免一次性轰炸用户。
- Handoffs（推荐下游）：
writing-plans（实施计划编写）：把设计变成可执行计划prd-engineer（需求工程师）：当需要 PRD / 验收标准 / Issues 拆解时先补齐
反模式："这太简单了，不需要设计"
所有项目都必须走这个流程——待办清单、单函数工具、配置变更，全部如此。"简单"项目恰恰是未经审视的假设造成最多返工的地方。设计可以很短（对于真正简单的项目几句话就够），但你必须展示设计并获得确认。
工作流
检查清单（按序完成，每项创建一个 Todo 任务）
- 探索项目上下文 — 检查文件、文档、最近的提交
- 评估范围 — 判断是否需要拆分为多个子项目
- 澄清问题 — 每次一个问题，理解目的/约束/成功标准
- 提出 2-3 个方案 — 带权衡分析，给出推荐
- 分节展示设计 — 每节获得用户确认后再继续
- 编写设计文档 — 保存到
docs/specs/YYYY-MM-DD-<主题>-设计.md
- 文档自检循环 — 派发文档审查子代理（见
references/spec-reviewer-prompt.md），发现问题则修复后重新审查（最多 3 轮，超出则交人工处理）
- 等待用户审阅 — 请用户在继续前审阅设计文档
- 转入实施规划 — 调用实施计划技能（如有）
流程详解
第一步：理解想法
- 先检查当前项目状态（文件、文档、最近提交），再提问
- 先评估范围：如果请求涵盖多个独立子系统，立即指出，不要在细节上浪费提问次数
- 如果项目过大，帮助用户拆分子项目：各部分是什么、如何关联、构建顺序如何？然后对第一个子项目走完整设计流程
- 对范围合适的项目，每次只问一个问题逐步澄清需求
- 优先使用选择题，比开放式问题更容易回答
- 聚焦于：目的、约束、成功标准
第二步：探索方案
- 提出 2-3 个不同方案及其权衡
- 用对话方式呈现选项，说明推荐及理由
- 以推荐方案开头并解释选择原因
第三步：展示设计
- 一旦充分理解要构建什么，就展示设计
- 每节根据复杂度调整篇幅：简单的几句话，复杂的不超过 200-300 字
- 每节展示后询问是否符合预期，再继续
- 覆盖：架构、核心组件、数据流、错误处理、测试策略
- 如有不清楚的地方随时回头澄清
第四步：设计隔离与清晰度
- 将系统拆分为更小的单元，每个单元有单一职责、清晰接口，可独立理解和测试
- 对每个单元应能回答：它做什么、如何使用、依赖什么
- 判断标准：不看内部实现能否理解这个单元？修改内部实现是否会破坏使用方？否则需要重新划分边界
- 更小、边界更清晰的单元也更容易让 AI 工作——上下文能容纳的代码越少越好，文件过大往往是做了太多事情的信号
第五步：在已有代码库中工作
- 提出变更前先探索现有结构，遵循已有模式
- 如果现有代码有影响当前工作的问题（文件过大、边界不清、职责混乱），将针对性改进纳入设计——就像优秀开发者改进他们正在接触的代码一样
- 不要提议无关的重构，专注于服务当前目标
设计文档
设计通过验证后：
- 将设计（规格说明）写入
docs/specs/YYYY-MM-DD-<主题>-设计.md
- 提交到 git
文档自检循环
写完文档后：
- 派发文档审查子代理（见
references/spec-reviewer-prompt.md）
- 如有问题：修复后重新派发，直到通过
- 如果循环超过 3 轮，交人工处理
用户审阅门控
自检循环通过后，请用户审阅：
"设计文档已写入 <路径>。请审阅，如需修改请告知，确认后我们开始编写实施计划。"
等待用户回复。如有修改需求，执行后重跑自检循环。用户确认后才能继续。
关键原则
| 原则 | 说明 |
|---|
| 每次一个问题 | 不要用多个问题淹没用户 |
| 优先选择题 | 比开放式问题更容易回答 |
| 无情地 YAGNI | 从所有设计中去掉不必要的功能 |
| 探索替代方案 | 在确定方案前始终提出 2-3 个选项 |
| 渐进式验证 | 展示设计，获得批准后再继续 |
| 保持灵活 | 有不清楚的地方随时回头澄清 |
警告：当你想跳过设计时
遇到以下想法，立刻停下——先完成设计流程：
| 借口 | 现实 |
|---|
| "需求很清楚，直接写代码" | 清楚的需求 ≠ 明确的约束与边界。少 2 分钟问题 = 多 2 小时返工。 |
| "太简单了不需要设计" | 简单项目里未审视的假设造成最多浪费。设计可以很短，但不能没有。 |
| "用户肯定想要这个功能" | "肯定"不是确认。问清楚。 |
| "我已经知道该怎么做了" | 你知道怎么做 ≠ 用户想要你那样做。先对齐。 |
| "只是一个小改动" | 小改动也会破坏接口、引入回归、违背用户预期。走流程。 |
参考资源
references/spec-reviewer-prompt.md — 文档审查子代理提示词模板
