Superpowers Brainstorming - 想法到设计

---

name: superpowers-brainstorming

description: Use before any creative work - creating features, building components, adding functionality, or modifying behavior - guides through exploration, questioning, design proposal, and spec documentation before any implementation

---

# Superpowers Brainstorming - 想法到设计

核心准则

**在创造性工作之前，通过协作对话将想法转化为完整的设计和规格说明。**

**触发条件：** 创建功能、构建组件、添加功能、修改行为。

硬性门槛

在调用任何实现技能、写任何代码、搭建任何项目、或采取任何实现动作之前，
必须先展示设计并获得主人批准。
无论感知到的复杂度如何，每个项目都要走这个流程。

"简单"项目正是未审视假设造成最多浪费的地方。设计可以很短（真正简单的项目几句话就够），但必须展示并获得批准。

流程检查表

按顺序完成每个任务：

1. **探索项目上下文** — 检查文件、文档、最近提交

2. **提出视觉化同伴**（如果主题涉及视觉问题）— 这是独立消息，不与澄清问题合并

3. **提出澄清问题** — 一次一个，理解目的/约束/成功标准

4. **提出 2-3 种方案** — 带有权衡和推荐

5. **展示设计** — 按复杂度缩放各部分，在每个部分后获批准

6. **写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit

7. **规格自审** — 快速内联检查占位符、矛盾、模糊、范围

8. **主人审查书面规格** — 在继续之前请主人审查规格文件

9. **过渡到实现** — 调用 `superpowers-writing-plans` 技能创建实现计划

**终点状态是调用 writing-plans。不要调用任何其他实现技能。**

流程详解

理解想法

探索方案

展示设计

为隔离和清晰而设计

现有代码库中工作

设计之后

**文档：**

**规格自审：**

写完规格文档后，用新眼光看：

1. **占位符扫描：** 有"TBD"、"TODO"、不完整部分或模糊需求吗？修复它们。

2. **内部一致性：** 各部分有矛盾吗？架构和功能描述匹配吗？

3. **范围检查：** 这个范围对于单一实现计划够聚焦吗？需要分解吗？

4. **模糊检查：** 任何需求能有两种解释吗？如果有，选一个并明确。

内联修复问题。不需要重新审查——修复并继续。

**主人审查门槛：**

规格审查循环通过后，在继续之前请主人审查书面规格：

> "规格已写完并 commit 到 `<path>`。请审查，如果有要修改的告诉我，在我们开始写实现计划之前。"

等主人回复。如果请求变更，做修改并重新运行规格审查循环。只有在主人批准后才能继续。

**实现：**

关键原则

视觉化同伴（Canvas）

当预期接下来的问题涉及视觉内容时（模型、布局图、图表），提供 canvas 展示：

- **用 canvas：** 内容本身是视觉的——模型、线框图、布局对比、架构图、并排视觉设计

- **用文字：** 内容是文字的——需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策

关于 UI 主题的问题不自动是视觉问题。"在这个语境中个性意味着什么？"是概念问题——用文字。"哪种向导布局更好？"是视觉问题——用 canvas。

执行检查表

每次开始创意工作前，确认：