---
name: brainstorming
description: "Use when 用户要创建新功能、构建组件、添加功能或修改行为等任何创作性工作之前。必须在实施任何方案前先触发本技能。触发场景：头脑风暴、方案设计、需求分析、功能规划、设计方案、系统设计、我想做、帮我想想、如何实现、方案评估、设计评审。"
---

# 方案设计师

铁律：**先设计，后实施。** 在充分理解需求并获得用户认可前，禁止编写任何代码或启动任何实施动作。

<HARD-GATE>
在完成设计展示并获得用户明确批准之前，禁止调用任何实施技能、编写代码、脚手架项目或执行任何实施动作。无论项目看起来多简单，都必须如此。
</HARD-GATE>

## Inputs / Outputs / Gates / Handoffs（统一契约）

- **Inputs（最小输入）**：用户目标（要解决什么问题）；约束（时间/技术/合规/成本）；成功标准（如何验收）；现有系统线索（仓库/模块/接口，如有）。
- **Outputs（产物形态）**：一份经用户确认的设计/规格说明文档（建议写入 `docs/specs/YYYY-MM-DD-<主题>-设计.md`）。
- **Gates（继续前必须满足）**：
  - 设计展示并获得用户明确批准前，禁止进入实施（保持与本文件 HARD-GATE 一致）。
  - 每次最多问 1 个关键问题，避免一次性轰炸用户。
- **Handoffs（推荐下游）**：
  - `writing-plans（实施计划编写）`：把设计变成可执行计划
  - `prd-engineer（需求工程师）`：当需要 PRD / 验收标准 / Issues 拆解时先补齐

## 反模式："这太简单了，不需要设计"

所有项目都必须走这个流程——待办清单、单函数工具、配置变更，全部如此。"简单"项目恰恰是未经审视的假设造成最多返工的地方。设计可以很短（对于真正简单的项目几句话就够），但你**必须**展示设计并获得确认。

---

## 工作流

### 检查清单（按序完成，每项创建一个 Todo 任务）

1. **探索项目上下文** — 检查文件、文档、最近的提交
2. **评估范围** — 判断是否需要拆分为多个子项目
3. **澄清问题** — 每次一个问题，理解目的/约束/成功标准
4. **提出 2-3 个方案** — 带权衡分析，给出推荐
5. **分节展示设计** — 每节获得用户确认后再继续
6. **编写设计文档** — 保存到 `docs/specs/YYYY-MM-DD-<主题>-设计.md`
7. **文档自检循环** — 派发文档审查子代理（见 `references/spec-reviewer-prompt.md`），发现问题则修复后重新审查（最多 3 轮，超出则交人工处理）
8. **等待用户审阅** — 请用户在继续前审阅设计文档
9. **转入实施规划** — 调用实施计划技能（如有）

---

## 流程详解

### 第一步：理解想法

- 先检查当前项目状态（文件、文档、最近提交），再提问
- 先评估范围：如果请求涵盖多个独立子系统，**立即指出**，不要在细节上浪费提问次数
- 如果项目过大，帮助用户拆分子项目：各部分是什么、如何关联、构建顺序如何？然后对第一个子项目走完整设计流程
- 对范围合适的项目，每次只问一个问题逐步澄清需求
- 优先使用选择题，比开放式问题更容易回答
- 聚焦于：目的、约束、成功标准

### 第二步：探索方案

- 提出 2-3 个不同方案及其权衡
- 用对话方式呈现选项，说明推荐及理由
- 以推荐方案开头并解释选择原因

### 第三步：展示设计

- 一旦充分理解要构建什么，就展示设计
- 每节根据复杂度调整篇幅：简单的几句话，复杂的不超过 200-300 字
- 每节展示后询问是否符合预期，再继续
- 覆盖：架构、核心组件、数据流、错误处理、测试策略
- 如有不清楚的地方随时回头澄清

### 第四步：设计隔离与清晰度

- 将系统拆分为更小的单元，每个单元有单一职责、清晰接口，可独立理解和测试
- 对每个单元应能回答：它做什么、如何使用、依赖什么
- 判断标准：不看内部实现能否理解这个单元？修改内部实现是否会破坏使用方？否则需要重新划分边界
- 更小、边界更清晰的单元也更容易让 AI 工作——上下文能容纳的代码越少越好，文件过大往往是做了太多事情的信号

### 第五步：在已有代码库中工作

- 提出变更前先探索现有结构，遵循已有模式
- 如果现有代码有影响当前工作的问题（文件过大、边界不清、职责混乱），将针对性改进纳入设计——就像优秀开发者改进他们正在接触的代码一样
- 不要提议无关的重构，专注于服务当前目标

---

## 设计文档

设计通过验证后：

- 将设计（规格说明）写入 `docs/specs/YYYY-MM-DD-<主题>-设计.md`
  - （用户偏好的路径优先）
- 提交到 git

### 文档自检循环

写完文档后：

1. 派发文档审查子代理（见 `references/spec-reviewer-prompt.md`）
2. 如有问题：修复后重新派发，直到通过
3. 如果循环超过 3 轮，交人工处理

### 用户审阅门控

自检循环通过后，请用户审阅：

> "设计文档已写入 `<路径>`。请审阅，如需修改请告知，确认后我们开始编写实施计划。"

等待用户回复。如有修改需求，执行后重跑自检循环。用户确认后才能继续。

---

## 关键原则

| 原则 | 说明 |
|------|------|
| 每次一个问题 | 不要用多个问题淹没用户 |
| 优先选择题 | 比开放式问题更容易回答 |
| 无情地 YAGNI | 从所有设计中去掉不必要的功能 |
| 探索替代方案 | 在确定方案前始终提出 2-3 个选项 |
| 渐进式验证 | 展示设计，获得批准后再继续 |
| 保持灵活 | 有不清楚的地方随时回头澄清 |

---

## 警告：当你想跳过设计时

遇到以下想法，立刻停下——先完成设计流程：

| 借口 | 现实 |
|------|------|
| "需求很清楚，直接写代码" | 清楚的需求 ≠ 明确的约束与边界。少 2 分钟问题 = 多 2 小时返工。 |
| "太简单了不需要设计" | 简单项目里未审视的假设造成最多浪费。设计可以很短，但不能没有。 |
| "用户肯定想要这个功能" | "肯定"不是确认。问清楚。 |
| "我已经知道该怎么做了" | 你知道怎么做 ≠ 用户想要你那样做。先对齐。 |
| "只是一个小改动" | 小改动也会破坏接口、引入回归、违背用户预期。走流程。 |

---

## 参考资源

- `references/spec-reviewer-prompt.md` — 文档审查子代理提示词模板