brainstorming SKILL技能完整中文翻译版
brainstorming SKILL技能完整中文翻译版，并保持 Claude Code Skill 格式兼容。
我做的处理：
- 保留 YAML frontmatter 格式；
- 保留
name、description字段； - 保留
<HARD-GATE>等控制标签； - 保留 Mermaid/DOT 流程图结构；
- 将英文说明翻译成中文；
- 保持 Claude Code skill 语义不变；
- 文件可直接保存为：
skills/brainstorming/SKILL.md
---
name: brainstorming
description: "在任何创造性工作之前必须使用此技能——创建功能、构建组件、增加功能或修改行为。用于在实现之前探索用户意图、需求和设计。"
---
# 将想法通过头脑风暴转化为设计方案
通过自然的协作式对话，将想法逐步完善为完整的设计方案和规格说明。
首先了解当前项目上下文，然后逐个提出问题来完善想法。当你理解了要构建的内容后，提出设计方案并获得用户批准。
<HARD-GATE>
在展示设计方案并获得用户批准之前：
- 不得调用任何实现类 skill；
- 不得编写任何代码；
- 不得创建项目结构；
- 不得执行任何实现操作。
此规则适用于所有项目，无论项目看起来多么简单。
</HARD-GATE>
## 反模式："这个项目太简单，不需要设计"
所有项目都必须经过这个流程。
待办事项列表、单个函数工具、配置修改等简单任务也不例外。
简单项目往往最容易因为未考虑的假设而浪费时间。
设计可以很短：
- 真正简单的项目只需要几句话；
- 复杂项目需要完整设计。
但必须先提出设计并获得用户批准。
# 检查清单
你必须为以下每项创建任务，并按顺序完成：
1. **探索项目上下文**
- 检查文件；
- 查看文档；
- 查看最近提交记录。
2. **适时提供视觉辅助**
- 不要提前提供；
- 第一次遇到“通过图形展示会比文字描述更清楚”的问题时再提供；
- 如果整个过程没有出现视觉需求，则不要提供。
3. **提出澄清问题**
- 一次只能问一个问题；
- 理解目标、限制条件和成功标准。
4. **提出 2-3 种方案**
- 比较不同方案；
- 分析优缺点；
- 给出推荐方案。
5. **展示设计方案**
- 按复杂度分章节展示；
- 每个章节展示后等待用户确认。
6. **编写设计文档**
保存到：
docs/superpowers/specs/YYYY-MM-DD-
并提交 git。
7. **设计文档自检**
检查：
- 占位符；
- 矛盾；
- 范围；
- 模糊需求。
8. **用户审核设计文档**
要求用户检查设计文档。
9. **进入实现阶段**
调用：
writing-plans skill
创建实现计划。
---
# 流程图
```dot
digraph brainstorming {
"探索项目上下文" [shape=box];
"提出澄清问题" [shape=box];
"提出2-3种方案" [shape=box];
"展示设计方案" [shape=box];
"用户批准设计？" [shape=diamond];
"编写设计文档" [shape=box];
"设计自检\n(直接修复)" [shape=box];
"用户审核文档？" [shape=diamond];
"调用 writing-plans" [shape=doublecircle];
"探索项目上下文" -> "提出澄清问题";
"提出澄清问题" -> "提出2-3种方案";
"提出2-3种方案" -> "展示设计方案";
"展示设计方案" -> "用户批准设计？";
"用户批准设计？"
-> "展示设计方案"
[label="否，需要修改"];
"用户批准设计？"
-> "编写设计文档"
[label="是"];
"编写设计文档"
-> "设计自检\n(直接修复)";
"设计自检\n(直接修复)"
-> "用户审核文档？";
"用户审核文档？"
-> "编写设计文档"
[label="需要修改"];
"用户审核文档？"
-> "调用 writing-plans"
[label="批准"];
}
终止状态
流程最终状态必须是：
调用 writing-plans skill
不要调用：
- frontend-design；
- mcp-builder；
- 其他实现类 skill。
在 brainstorming 之后，唯一允许调用的是：
writing-plans
工作流程
理解想法
首先了解项目
必须先：
- 检查当前项目状态；
- 查看目录结构；
- 阅读已有文档；
- 查看最近提交。
判断项目规模
如果需求包含多个独立系统，例如：
创建一个包含聊天、文件存储、支付和分析的平台
需要立即指出：
该项目范围过大，需要拆分。
不要继续深入细化一个无法一次完成的大项目。
应该帮助用户拆分：
- 哪些是独立模块；
- 模块之间关系；
- 开发顺序。
然后选择第一个子项目进入正常设计流程。
对合理范围项目
按照以下原则：
-
一次只问一个问题；
-
优先使用选择题；
-
重点理解：
- 目的；
- 限制；
- 成功标准。
探索方案
必须提出：
2-3 个不同方案。
包括：
- 优点；
- 缺点；
- 权衡。
优先提出推荐方案，并说明原因。
展示设计
当理解需求后：
展示设计方案。
复杂度控制：
简单项目：
几句话即可。
复杂项目：
每部分最多约：
200-300 字。
每个设计章节结束后：
询问用户是否认可。
设计内容包括：
- 架构；
- 组件；
- 数据流；
- 错误处理；
- 测试策略。
如果发现问题：
返回澄清。
设计隔离原则
设计应保证：
- 每个模块只有一个明确职责；
- 模块通过明确接口通信；
- 每个模块可以独立理解和测试。
对于每个模块，需要回答：
- 它做什么？
- 如何使用？
- 依赖什么？
如果：
必须阅读内部实现才能理解模块作用
说明边界设计不好。
小而清晰的模块：
- 更容易维护；
- 更容易测试；
- 更容易修改。
修改已有代码库
处理已有项目时：
必须：
- 先了解结构；
- 遵循现有模式。
如果已有代码存在影响当前工作的设计问题：
可以提出针对性改进。
不要：
- 顺手重构无关代码；
- 扩大任务范围。
设计完成后
文档
保存：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
如果存在：
elements-of-style:writing-clearly-and-concisely
skill：
使用它改善文档。
提交：
git commit
设计自检
完成设计文档后：
重新阅读。
检查：
1. 占位符
寻找：
- TBD
- TODO
- 未完成内容
- 模糊描述
发现后直接修复。
2. 一致性
检查：
- 架构是否匹配功能；
- 是否存在冲突。
3. 范围
确认：
- 是否适合一个实现计划；
- 是否需要拆分。
4. 歧义
如果需求可能有多种理解：
选择一种并明确写出。
用户审核
设计文档完成后：
告诉用户：
"设计文档已经编写并提交到
<path>。请检查该文件，如果需要修改请告诉我，然后我们再开始编写实现计划。"
等待用户回复。
如果用户要求修改：
修改文档。
重新执行自检。
只有用户批准后：
才能继续。
实现阶段
调用：
writing-plans skill
创建详细实现计划。
不要调用其他 skill。
核心原则
一次一个问题
不要一次提出多个问题。
优先选择题
选择题更容易回答。
YAGNI
坚决删除不必要功能。
探索多个方案
始终比较 2-3 个方案。
增量确认
设计 → 用户批准 → 下一步。
灵活调整
发现理解错误：
返回澄清。
Visual Companion（视觉辅助）
视觉辅助是一个浏览器工具：
用于展示：
- 原型；
- 图表；
- 布局；
- 对比方案。
它不是默认流程。
提供时机
不要提前提供。
只有第一次遇到：
使用图片/图形比文字更容易理解的问题
才提供。
必须单独发送：
"接下来部分如果通过展示可能更容易理解。我可以在浏览器标签页中展示原型、图表和方案比较。需要使用吗？"
等待用户回复。
如果用户接受：
读取：
skills/brainstorming/visual-companion.md
然后启动。
每个问题独立判断
即使用户接受视觉辅助：
每个问题仍需判断。
使用浏览器：
- UI 原型；
- 布局；
- 架构图；
- 视觉比较。
使用文字：
- 需求问题；
- 概念选择；
- 范围讨论。
关键规则
不要因为：
"这是一个 UI 项目"
就自动使用视觉工具。
只有：
看见比阅读更清楚
才使用。
这个版本可以直接作为 Claude Code 的 `SKILL.md` 使用。建议目录：
```text
.claude/
└── skills/
└── brainstorming/
└── SKILL.md
或者：
~/.claude/skills/brainstorming/SKILL.md
然后 Claude Code 会把它识别为一个 skill。
浙公网安备 33010602011771号