superpowers skill 2.1: brainstorming-程序员充电站

智能体工作流程

安装

$ npx skills add https://github.com/obra/superpowers --skill brainstorming

摘要

结构化设计对话，在实施开始前验证想法。

强制执行硬性关卡：在设计方案提交并获得批准之前，不得编写代码、搭建脚手架或执行实施操作
指导完成九个连续步骤：上下文探索、澄清问题、方法提案、设计展示、规范文档、审查循环和用户签字确认
适用于所有项目，无论其感知复杂性如何；即使是简单的任务也需要简短的设计审查以发现未经检验的假设
包含可选的视觉辅助工具，用于头脑风暴期间的模型、图表和布局比较
通过调用写作计划技能来创建实施路线图来终止流程

SKILL.md

将头脑风暴的想法转化为设计

通过自然的协作对话帮助将想法转化为完整的设计和规格。

首先了解当前的项目背景，然后逐个提出问题以完善想法。一旦理解了要构建的内容，就展示设计并获得用户批准。

反模式：“这太简单了，不需要设计”

每个项目都要经历这个过程。待办事项列表、单功能实用程序、配置更改——都是如此。"简单"的项目是未经检验的假设导致最多工作浪费的地方。设计可以很简短（对于真正简单的项目只需几句话），但您必须展示它并获得批准。

清单

您必须为以下每项内容创建一个任务，并按顺序完成：

探索项目上下文— 检查文件、文档、最近的提交
提供视觉辅助工具（如果主题涉及视觉问题）—— 这是一条独立的消息，不与澄清问题结合。参见下面的视觉辅助工具部分。
提出澄清问题— 一次一个问题，了解目的/限制条件/成功标准
提出2-3种方法— 带有权衡和您的推荐
展示设计方案— 按复杂程度分节，每节后获得用户批准
编写设计文档— 保存到docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md并提交
规范自审— 快速内联检查占位符、矛盾、歧义、范围（见下文）
用户审查书面规范— 要求用户在继续之前审查规范文件
过渡到实施— 调用写作计划技能创建实施计划

流程图

digraph brainstorming { "探索项目上下文" [shape=box]; "涉及视觉问题？" [shape=diamond]; "提供视觉辅助工具\n（独立消息，无其他内容）" [shape=box]; "提出澄清问题" [shape=box]; "提出2-3种方法" [shape=box]; "展示设计方案各节" [shape=box]; "用户批准设计方案？" [shape=diamond]; "编写设计文档" [shape=box]; "规范自审\n（内联修复）" [shape=box]; "用户审查规范？" [shape=diamond]; "调用写作计划技能" [shape=doublecircle]; "探索项目上下文" -> "涉及视觉问题？"; "涉及视觉问题？" -> "提供视觉辅助工具\n（独立消息，无其他内容）" [label="是"]; "涉及视觉问题？" -> "提出澄清问题" [label="否"]; "提供视觉辅助工具\n（独立消息，无其他内容）" -> "提出澄清问题"; "提出澄清问题" -> "提出2-3种方法"; "提出2-3种方法" -> "展示设计方案各节"; "展示设计方案各节" -> "用户批准设计方案？"; "用户批准设计方案？" -> "展示设计方案各节" [label="否，修订"]; "用户批准设计方案？" -> "编写设计文档" [label="是"]; "编写设计文档" -> "规范自审\n（内联修复）"; "规范自审\n（内联修复）" -> "用户审查规范？"; "用户审查规范？" -> "编写设计文档" [label="要求修改"]; "用户审查规范？" -> "调用写作计划技能" [label="批准"]; }

最终状态是调用写作计划。不要调用前端设计、mcp-builder或任何其他实现技能。头脑风暴之后您唯一能调用的技能就是写作计划。

流程

理解想法：

首先查看当前项目状态（文件、文档、最近的提交）
在提出详细问题之前，评估范围：如果请求描述了多个独立子系统（例如，“构建一个具有聊天、文件存储、计费和分析功能的平台”），立即标记这一点。不要花费问题来完善需要首先分解的项目的细节。
如果项目太大，无法用单个规范完成，帮助用户分解为子项目：独立的部分是什么，它们如何关联，应该按什么顺序构建？然后通过正常的设计流程对第一个子项目进行头脑风暴。每个子项目都有自己的规范→计划→实施周期。
对于适当规模的项目，一次提出一个问题来完善想法
尽可能使用选择题，但开放式问题也可以
每条消息只问一个问题 - 如果某个主题需要更多探索，将其拆分为多个问题
专注于理解：目的、限制、成功标准

探索方法：

提出2-3种不同的方法及其权衡
以对话方式呈现选项，包括您的建议和理由
首先介绍您推荐的选项并解释原因

展示设计：

一旦您认为理解了要构建的内容，就展示设计
根据复杂程度调整每节的规模：如果是直截了当的话几句话，如果是细致入微的话最多200-300字
在每节之后询问目前是否看起来正确
涵盖：架构、组件、数据流、错误处理、测试
准备好回头澄清，如果某些内容没有意义

隔离和清晰度设计：

将系统分解为更小的单元，每个单元都有一个明确的目的，通过定义良好的接口进行通信，并且可以独立理解和测试
对于每个单元，您应该能够回答：它做什么，如何使用它，以及它依赖什么？
有人能否在不阅读其内部的情况下理解单元的作用？您能否在不破坏使用者的情况下更改内部？如果不是，则边界需要改进。
更小、界限清晰的单元也更容易让您处理 - 当您可以一次性掌握上下文中的代码时，您的推理会更好，当文件集中时，您的编辑更可靠。当文件变得很大时，通常表明它承担了太多工作。

在现有代码库中工作：

在提议更改之前探索当前结构。遵循现有模式。
当现有代码有问题影响工作时（例如，文件变得过大、边界不清、责任纠缠），将有针对性的改进作为设计的一部分 - 好开发人员改进他们正在工作的代码的方式。
不要提议无关的重构。专注于服务当前目标的内容。

设计之后

文档：

将经过验证的设计（规范）写入
```
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
```
- （用户对规范位置的偏好优先于此默认值）
如果可用，请使用elements-of-style:writing-clearly-and-concisely技能
将设计文档提交到git

规范自审：写完规范文档后，用新的眼光看待它：