# Brainstorming

> 在任何创意工作（创建功能、构建组件、添加功能或修改行为）之前必须使用本技能。在实现前先探索用户意图、需求和设计方案。触发场景：用户描述想构建什么、分享功能想法或提供简要需求清单时。

- Skill: `idwong/brainstorming` (Agent Skill)
- Install (CLI): `npx skillmds@latest add idwong/brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/idwong/brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: iDWong (https://skillmd.com/u/idwong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/idwong/brainstorming

---


# 头脑风暴：从想法到设计方案

通过自然对话将用户的想法或需求清单转化为完整的设计方案，确认后保存文档，再询问是否生成SRS需求规格说明书。

<HARD-GATE>
在展示设计方案并获得用户确认之前，禁止编写任何代码、生成文件或执行任何实现操作。

即使需求看起来很简单，也必须经过此流程。"太简单了不需要设计"是最常见的跳过理由，也是最常见的返工原因。设计可以很短，但必须展示并获得确认。
</HARD-GATE>

## 流程

```
理解输入 → 澄清问题（逐个） → 提出方案 → 展示设计 → 用户确认 → 保存文档 → 询问是否生成SRS
```

## 第一步：理解输入

**模式 A：用户描述想法**（"我想做 xxx"）
- 探索项目当前上下文（文件、文档等）
- 逐一提问澄清：目的、用户群体、关键功能、约束条件
- 每次只问一个问题，优先给出选项供用户选择

**模式 B：用户提供需求清单**
- 审查清单，识别：遗漏、模糊、矛盾、边界不清
- 针对问题逐一提问澄清
- 需求清单完整清晰后，才进入方案设计

## 第二步：提出方案

- 提出 2-3 种实现思路，附上优缺点对比
- 给出明确的推荐方案及理由
- 用对话式语言，不要过于技术化

## 第三步：展示设计方案

按模块分节展示，覆盖：功能范围与核心模块、界面/交互设计（如适用）、数据结构与流向、关键边界情况处理。

展示完整设计后询问：
> "以上是完整的设计方案，请问有什么需要调整的地方吗？"

## 第四步：确认并保存

用户确认后，先展示任务清单，再逐个执行。

**文件命名规范：**
`prd/planning/{YYYY-MM-DD}-{客户名称}{系统名称}-设计方案-v1.0.md`
- 示例：`prd/planning/2026-05-04-PM能源智慧厂区巡检系统-设计方案-v1.0.md`
- 同名文件已存在时自动递增版本号（v1.1, v1.2...）
- 与 req-doc 技能的命名风格保持一致（日期-客户名称项目名称-文档类型-版本号）

**任务清单格式：**
```
| 序号 | 任务名称 | 状态 |
|------|---------|------|
| 1 | 创建文件 - 文档头部 + 项目概述 | [ ] 等待中 |
| 2 | 追加 - 功能范围 | [ ] 等待中 |
| 3 | 追加 - 核心模块设计 | [ ] 等待中 |
| 4 | 追加 - 数据结构与流向 | [ ] 等待中 |
| 5 | 追加 - 边界情况处理 | [ ] 等待中 |
```

状态标识：[ ] 等待中 → [进行中] → [完成]

**执行规则：**
1. 每次只执行一个任务，执行前更新为 [进行中]，完成后更新为 [完成]，重新展示清单
2. **任务1**：用 Write 工具创建文件，写入文档头部和项目概述
3. **任务2及之后**：必须先用 Read 工具读取文件当前内容，再用 Edit 工具追加新内容
   - 不 Read 直接 Edit 会报错，必须严格遵守
   - 每次追加不超过 150 行，内容过多时拆分为多个任务
4. 禁止跳过状态更新，禁止批量执行，禁止一次性写入整个文档
5. 每个任务完成后验证文件内容正确，再进入下一个任务

**文档结构参考：**
```markdown
---
title: "[系统名称]设计方案"
date: "[日期]"
version: "v1.0"
---

# [系统名称]设计方案

## 一、项目概述

[项目背景、目标、核心价值]

## 二、功能范围

[核心功能模块列表和说明]

## 三、核心模块设计

[每个模块的详细设计：功能说明、交互逻辑、数据流向]

## 四、数据结构与流向

[关键数据实体、数据流转关系]

## 五、边界情况处理

[异常场景、权限控制、特殊业务规则]
```

## 第五步：后续行动

保存完成后询问（**快速模式**下可合并为一句）：

> 设计文档已保存。接下来：**SRS（req-doc）**、**PRD（prd-writer）**，或暂不需要？  
> 也可说「快速模式 + PRD」直接出稿。  
> **若选 PRD 且后续要开发** → PRD 确认后须 **`req-doc` Step F** 转 SRS，再 `page-generator`（见 `../common/prd-to-srs-gate.md`）。

- **SRS** → `req-doc`
- **PRD** → `prd-writer`（可说「跳过概念版」走快路径；进研发时 Step F）
- **否** → 告知可随时生成；歧义时见 `AGENTS.md` 路由与交付模式

## 关键原则

- 每次只问一个问题，优先给选项
- YAGNI：去掉不必要的功能，保持设计简洁
- 分节展示设计，及时发现偏差，用户有异议时随时回退修改