从创意到设计
通过自然的协作对话，将创意转化为完整的设计和规格说明。
首先了解当前项目上下文，然后逐个提问以细化想法。在完全理解你要构建的内容后，呈现设计方案并获得用户批准。
反模式：“这太简单了，不需要设计”
每个项目都必须经历这个流程。无论是待办事项列表、单功能工具、还是配置变更——所有项目都无一例外。“简单”的项目恰恰是那些未经检验的假设导致最大浪费的地方。设计可以简短（对于真正简单的项目只需几句话），但必须先呈现并获得批准。
检查清单
你必须为以下每个项目创建一个任务，并按顺序完成：
- 探索项目上下文 — 检查文件、文档、最近的提交记录
- 提出澄清问题 — 逐个提问，理解目的/约束/成功标准
- 提出 2-3 种方案 — 附带权衡分析及你的推荐
- 呈现设计 — 按复杂度划分章节，每章获得用户批准后再继续
- 编写设计文档 — 保存至
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md并提交 - 规范自检 — 快速内联检查是否存在占位符、矛盾、歧义、范围问题
- 用户审查书面规范 — 请用户审查规范文件，然后再继续
- 过渡到实现 — 调用 writing-plans 技能以创建实现计划
流程
flowchart TD
A[探索项目上下文] --> B[提出澄清问题]
B --> C[提出 2-3 种方案]
C --> D[呈现设计章节]
D --> E{用户批准设计?}
E -- 否，修订 --> D
E -- 是 --> F[编写设计文档]
F --> G[规范自检<br/>内联修复]
G --> H{用户审查规范?}
H -- 请求修改 --> F
H -- 批准 --> I[调用 writing-plans 技能]
最终状态是调用 writing-plans。 不得调用任何实现技能。在此之后你唯一能调用的技能是 writing-plans。
流程细节
理解创意：
- 首先查看当前项目状态（文件、文档、最近的提交记录）
- 在询问详细问题之前，评估范围：如果请求描述了多个独立的子系统（例如“构建一个包含聊天、文件存储、计费和分析的平台”），应立即标记出来。不要将问题浪费在细化一个需要首先分解的项目的细节上。
- 如果项目太大无法用单一规格说明覆盖，帮助用户将其分解为子项目：有哪些独立的部分？它们之间如何关联？应该按什么顺序构建？然后通过正常流程设计第一个子项目。每个子项目都有其自己的规格说明 → 计划 → 实现循环。
- 对于范围适当的项目，逐个提问以细化想法
- 尽可能使用选择题，但开放性问题也可以
- 每条消息只提一个问题——如果某个主题需要更多探索，将其分解为多个问题
- 关注理解：目的、约束、成功标准
探索方案：
- 提出 2-3 种不同方案，附带权衡分析
- 以对话方式呈现选项，附上你的推荐和理由
- 首先给出你推荐的选项并解释原因
呈现设计：
- 一旦你认为自己理解了要构建的内容，就呈现设计
- 每个章节按复杂度缩放：如果简单易懂则只需几句话，如果较为复杂则可以长达 200-300 词
- 每章结束后询问：到目前为止是否正确
- 涵盖：架构、组件、数据流、错误处理、测试
- 准备好，如果某些内容不合理，可以后退并澄清
为隔离性和清晰度而设计：
- 将系统分解为更小的单元，每个单元只有一个明确的用途，通过定义良好的接口进行通信，并且可以独立理解和测试
- 对于每个单元，你应该能回答：它做什么？如何使用？它依赖什么？
- 不阅读内部实现是否就能理解一个单元的功能？能否在不破坏使用者的前提下更改内部实现？如果不能，说明边界需要改进。
- 更小的、边界良好的单元也让你更容易处理——你能够更好地推理那些可以一次放入上下文的代码，并且当文件聚焦时，你的编辑更可靠。当一个文件变得很大时，这通常是一个信号，表明它做得太多。
在现有代码库中工作：
- 在提出更改之前，探索现有结构。遵循现有模式。
- 如果现有代码存在影响工作的问题（例如文件变得太大、边界不清晰、职责混乱），则将这些有针对性的改进作为设计的一部分——就像优秀开发者在工作中改进代码那样。
- 不要提出不相关的重构。始终聚焦于服务当前目标。
设计之后
文档：
- 将验证过的设计（规格说明）写入
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md- （用户偏好中的规格说明位置会覆盖此默认路径）
- 将设计文档提交到 git
规范自检： 编写完规范文档后，用全新的视角审视它：
- 占位符扫描： 是否有“TBD”、“TODO”、不完整的章节或模糊的需求？修复它们。
- 内部一致性： 各章节之间是否存在矛盾？架构是否与功能描述匹配？
- 范围检查： 是否足够聚焦于单个实现计划，还是需要进一步分解？
- 歧义检查： 是否存在任何需求可以以两种不同方式解释？如果是，选择一种并明确说明。
内联修复所有问题。无需重新审查——直接修复并继续。
用户审查关卡： 在规范审查循环通过后，请用户在继续之前审查所编写的规范：
“规范已编写并提交到
<path>。请在开始编写实现计划之前审查它，并告知我是否要进行任何更改。”
等待用户响应。如果用户请求更改，则进行更改并重新运行规范审查循环。只有在用户批准后才可继续。
实现：
- 调用 writing-plans 技能以创建详细的实现计划
- 不要调用任何其他技能。writing-plans 是下一步。
关键原则
- 一次一个问题 — 不要用多个问题让用户不知所措
- 优先选择题 — 在可能的情况下，选择题比开放性问题更容易回答
- 严格执行 YAGNI — 从所有设计中移除不必要的功能
- 探索备选方案 — 在确定之前始终提出 2-3 种方案
- 增量验证 — 呈现设计，获得批准后再继续
- 保持灵活 — 当某些内容不合理时，后退并澄清
从上游技能中移除的内容
原始 brainstorming 技能（obra/superpowers）包含一个“视觉伴侣”功能：一个用于在头脑风暴期间在浏览器标签页中显示模拟界面的 Node.js 浏览器服务器（scripts/server.cjs、scripts/start-server.sh、scripts/stop-server.sh）。SkillSpector 因 stop-server.sh 中存在工具参数滥用而阻止了该技能。
此移植版本完全移除了视觉伴侣。核心方法论——协作设计对话、硬性关卡、规范自检、用户审查关卡、过渡到 writing-plans——是纯粹的过程指导，不包含任何脚本、shell 或外部服务器。它在结构上就是安全的。
如果需要在设计对话期间显示模拟界面或图表，请使用智能体的原生工具（浏览器 MCP 工具、图片生成或内联 Mermaid/ASCII 图表）代替捆绑的服务器。