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--design.md

并提交 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 字。

每个设计章节结束后：

询问用户是否认可。

设计内容包括：

• 架构；
• 组件；
• 数据流；
• 错误处理；
• 测试策略。

如果发现问题：

返回澄清。

---

设计隔离原则

设计应保证：

• 每个模块只有一个明确职责；
• 模块通过明确接口通信；
• 每个模块可以独立理解和测试。

对于每个模块，需要回答：

1. 它做什么？
2. 如何使用？
3. 依赖什么？

如果：

必须阅读内部实现才能理解模块作用

说明边界设计不好。

小而清晰的模块：

• 更容易维护；
• 更容易测试；
• 更容易修改。

---

修改已有代码库

处理已有项目时：

必须：

• 先了解结构；
• 遵循现有模式。

如果已有代码存在影响当前工作的设计问题：

可以提出针对性改进。

不要：

• 顺手重构无关代码；
• 扩大任务范围。

---

设计完成后

文档

保存：

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。