# Brainstorming

> 在任何创造性工作(做新功能、建组件、加能力、改行为)动手之前使用。通过结构化对话把模糊需求逼成清晰、经用户批准的设计,再进入写计划阶段。拿到批准前不写任何代码。

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

---


# 头脑风暴:先把需求想清楚

> 移植自 [superpowers](https://github.com/obra/superpowers)(MIT)。

## 硬性闸门

**在你拿出一份设计、且用户明确批准之前,不要写任何代码、不要搭脚手架、不要执行任何实现动作。**

在 deepx 里可以切到 `/plan` 模式(Write/Bash 关闭)做只读探索,从机制上挡住"手痒先写"。

## 流程

按顺序走,别跳:

1. **探索上下文**。用 `Read`/`Grep`/`Tree`/`CodeGraph` 摸清现有代码与约定,别凭空假设。
2. **一次只问一个问题**。不要一口气抛一堆问题压垮用户。问完一个,听完回答,再问下一个。
3. **提 2–3 种方案,讲清取舍**。不要默默选一个就上。把备选摆出来,说明各自的代价。
4. **分块呈现设计**:目标、模块划分、接口、数据流、边界情况。
5. **写下设计文档**(可放 `docs/` 下),不要只停留在对话里。
6. **自审**:设计是否完整?有没有没定的地方?有没有 YAGNI 该砍的?
7. **拿用户对"写下来的设计"的批准**——不是对口头描述的模糊点头。
8. 批准后再动手实现;先把工作拆成小步、每步想清"怎么算成功",再逐步写。拿到批准前不要写代码。

## 设计原则

- **拆成小单元**:每个单元一个清晰职责、通过明确接口通信、能被独立理解和测试。
- **狠心 YAGNI**:没要求的功能、没用到的"灵活性"、不可能发生的错误处理——全砍。
- **先提替代再定方案**:一上来就锁定单一方案,往往错过更简单的路。

## 红旗

- 还没拿到批准就开始写代码 / 建文件。
- 一次问用户五个问题。
- 只给一个方案,不讲取舍。
- 设计只在脑子里/对话里,没落成文字就开干。