安装方式
手动下载安装
下载 ZIP 后解压到技能目录即可安装。若在桌面客户端 WebView中直接下载出现异常，本站会改为提示页 + 原始链接，请按页内说明操作。
下载 ZIP (oss-superpowers-brainstorming-v1.0.0.zip)触发指令
/brainstorming
跨平台安装指引
该技能声明兼容以下 1 个平台，将 ZIP 解压到对应目录即可被识别。
unzip oss-superpowers-brainstorming-v1.0.0.zip -d ~/.claude/skills/
mkdir -p 创建；启用 Skill 后请重启对应 Agent 让配置生效。
使用指南
从想法到设计
通过自然对话，把想法打磨成 完整设计与规格。
先理解当前项目上下文，再 一次只问一个问题 细化需求；清楚要做什么后，呈现设计并请用户认可。
反模式：「太简单不需要设计」
所有 项目都走本流程。待办列表、单函数小工具、改配置——全部。所谓「简单」项目，往往是 未检验假设 导致返工最多的地方。设计可以很短（真简单时几句话），但必须 呈现并获批。
清单（须逐项建任务并按序完成）
- 探索项目上下文 — 看文件、文档、近期提交
- （若将涉及视觉问题）提供视觉伴侣 — 单独一条消息，不与澄清问题混发；见下文「视觉伴侣」
- 澄清问题 — 一次一个，弄清目的、约束、成功标准
- 提出 2–3 种方案 — 含权衡与你的推荐
- 分节呈现设计 — 复杂度决定每节篇幅；每节后询问是否 OK
- 撰写设计文档 — 保存到
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md并提交（用户若指定其他路径则从其偏好） - 规格自检 — 占位符、矛盾、歧义、范围（见下）
- 用户审阅成文规格 — 请用户读文件后再继续
- 转入实现规划 — 调用 writing-plans 技能写实现计划
流程说明（要点）
理解想法： 先看仓库现状；若请求包含多个独立大子系统，先 分解 再对 第一个子项目 走完整流程（每子项目：规格 → 计划 → 实现）。
探索方案： 给 2–3 种做法与权衡；推荐其一并说明理由。
呈现设计： 分节讲清架构、组件、数据流、错误处理、测试；每节确认后再继续。
隔离与清晰： 小模块、单职责、接口明确；每个单元能回答：做什么、怎么用、依赖什么。
存量代码： 先摸结构再提案；只围绕当前目标做 有针对性的 改进，不无关大重构。
设计之后
文档： 将Validated 设计写入上述路径；可用清晰写作类技能；提交 git。
规格自检： 扫 TBD/TODO、内部一致性、范围是否过大、是否有歧义；当场改，不必形式主义重审。
用户审阅门： 请用户读已提交规格；有修改则改完再问过；通过后才 进入 writing-plans。
实现： 只 调用 writing-plans。不要调用 frontend-design、mcp-builder 等实现技能。
原则
一次一问、偏好选择题、YAGNI、多方案比较、分步确认设计、必要时回头澄清。
视觉伴侣
浏览器里展示线框、示意图、视觉选项。是工具而非模式；用户同意只表示 可以 在需要时用浏览器，不是每个问题都要用。
提供方式： 当你预期接下来会有 视觉向 问题时，单独一条消息 询问是否愿意用本地 URL 打开浏览器看示意（说明可能较耗 token）。不要 与同条里的其他内容混发。拒绝则纯文本继续。
逐题判断： 即使用户同意，每道题仍要判断：看图是否比读文字更懂？ 概念题用终端；版式对比用浏览器。
用户同意后，细节见技能包内 skills/brainstorming/visual-companion.md。
<!-- zh-only -->
# 从想法到设计
通过自然对话，把想法打磨成 **完整设计与规格**。
先理解当前项目上下文，再 **一次只问一个问题** 细化需求；清楚要做什么后，呈现设计并请用户认可。
<HARD-GATE>
在 **向用户展示设计并得到认可之前**，不得调用任何 **实现类技能**、不得写代码、不得脚手架、不得采取任何实现动作。**任何** 项目都必须遵守，无论看起来多简单。
</HARD-GATE>
## 反模式：「太简单不需要设计」
**所有** 项目都走本流程。待办列表、单函数小工具、改配置——**全部**。所谓「简单」项目，往往是 **未检验假设** 导致返工最多的地方。设计可以很短（真简单时几句话），但必须 **呈现并获批**。
## 清单（须逐项建任务并按序完成）
1. **探索项目上下文** — 看文件、文档、近期提交
2. **（若将涉及视觉问题）提供视觉伴侣** — **单独一条消息**，不与澄清问题混发；见下文「视觉伴侣」
3. **澄清问题** — 一次一个，弄清目的、约束、成功标准
4. **提出 2–3 种方案** — 含权衡与你的推荐
5. **分节呈现设计** — 复杂度决定每节篇幅；每节后询问是否 OK
6. **撰写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并提交（用户若指定其他路径则从其偏好）
7. **规格自检** — 占位符、矛盾、歧义、范围（见下）
8. **用户审阅成文规格** — 请用户读文件后再继续
9. **转入实现规划** — 调用 **writing-plans** 技能写实现计划
## 流程说明（要点）
**理解想法：** 先看仓库现状；若请求包含多个独立大子系统，先 **分解** 再对 **第一个子项目** 走完整流程（每子项目：规格 → 计划 → 实现）。
**探索方案：** 给 2–3 种做法与权衡；推荐其一并说明理由。
**呈现设计：** 分节讲清架构、组件、数据流、错误处理、测试；每节确认后再继续。
**隔离与清晰：** 小模块、单职责、接口明确；每个单元能回答：做什么、怎么用、依赖什么。
**存量代码：** 先摸结构再提案；只围绕当前目标做 **有针对性的** 改进，不无关大重构。
## 设计之后
**文档：** 将Validated 设计写入上述路径；可用清晰写作类技能；**提交 git**。
**规格自检：** 扫 TBD/TODO、内部一致性、范围是否过大、是否有歧义；当场改，不必形式主义重审。
**用户审阅门：** 请用户读已提交规格；有修改则改完再问过；**通过后才** 进入 writing-plans。
**实现：** **只** 调用 **writing-plans**。不要调用 frontend-design、mcp-builder 等实现技能。
## 原则
一次一问、偏好选择题、YAGNI、多方案比较、分步确认设计、必要时回头澄清。
## 视觉伴侣
浏览器里展示线框、示意图、视觉选项。**是工具而非模式**；用户同意只表示 **可以** 在需要时用浏览器，不是每个问题都要用。
**提供方式：** 当你预期接下来会有 **视觉向** 问题时，**单独一条消息** 询问是否愿意用本地 URL 打开浏览器看示意（说明可能较耗 token）。**不要** 与同条里的其他内容混发。拒绝则纯文本继续。
**逐题判断：** 即使用户同意，每道题仍要判断：**看图是否比读文字更懂？** 概念题用终端；版式对比用浏览器。
用户同意后，细节见技能包内 `skills/brainstorming/visual-companion.md`。