superpowers-brainstorming

# 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。不要调用任何其他实现技能。** ## 流程详解 ### 理解想法 - 先检查当前项目状态（文件、文档、最近提交） - 在问详细问题前，评估范围：如果请求描述多个独立子系统（如"构建有聊天、文件存储、计费、分析的平台"），立即标记。不要在需要先分解的项目上花时间细化细节。 - 对于适当范围的项目，一次问一个问题来细化想法 - 尽量用多选问题，但开放问题也可以 - 一次只问一个问题——如果主题需要更多探索，拆成多个问题 - 重点理解：目的、约束、成功标准 ### 探索方案 - 提出 2-3 个不同方案，带权衡 - 用对话方式展示选项，说明推荐和原因 - 用推荐选项开头并解释为什么 ### 展示设计 - 一旦相信理解了要构建什么，就展示设计 - 每个部分按复杂度缩放：直接的几句话，复杂的 200-300 字 - 每个部分后问"这样看起来对吗" - 覆盖：架构、组件、数据流、错误处理、测试 - 如果有不明白的地方准备好回去澄清 ### 为隔离和清晰而设计 - 将系统分成更小的单元，每个有明确目的，通过清晰接口通信，可以独立理解和测试 - 对于每个单元，应该能回答：它做什么，你怎么用它，它依赖什么？ - 有人能在不读内部代码的情况下理解它做什么吗？能改变内部代码而不破坏消费者吗？如果不能，边界需要改进 - 更小、边界好的单元你也更容易处理——你更容易推理能放在脑子里的代码，编辑时也更可靠。当一个文件变大，通常是它做太多事的信号 ### 现有代码库中工作 - 在提出变更前先探索当前结构。遵循已有模式。 - 对于影响工作的现有代码问题（如长得太大的文件、边界不清、职责混乱），把针对性改进作为设计的一部分——好开发者在工作的代码中会做这些改进。 - 不要提无关的重构。聚焦于服务当前目标的内容。 ## 设计之后 **文档：** - 将经验证的设计（规格）写到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` - Commit 设计文档到 git **规格自审：** 写完规格文档后，用新眼光看： 1. **占位符扫描：** 有"TBD"、"TODO"、不完整部分或模糊需求吗？修复它们。 2. **内部一致性：** 各部分有矛盾吗？架构和功能描述匹配吗？ 3. **范围检查：** 这个范围对于单一实现计划够聚焦吗？需要分解吗？ 4. **模糊检查：** 任何需求能有两种解释吗？如果有，选一个并明确。 内联修复问题。不需要重新审查——修复并继续。 **主人审查门槛：** 规格审查循环通过后，在继续之前请主人审查书面规格： > "规格已写完并 commit 到 `<path>`。请审查，如果有要修改的告诉我，在我们开始写实现计划之前。" 等主人回复。如果请求变更，做修改并重新运行规格审查循环。只有在主人批准后才能继续。 **实现：** - 调用 `superpowers-writing-plans` 技能创建详细实现计划 - 不要调用其他技能。writing-plans 是下一步。 ## 关键原则 - **一次一个问题** — 不要用多个问题压垮 - **多选优先** — 比开放问题更容易回答 - **YAGNI 彻底** — 从所有设计中移除不必要功能 - **探索替代方案** — 在确定之前总是提出 2-3 个方案 - **增量验证** — 展示设计，获得批准后再继续 - **灵活** — 有不明白的回去澄清 ## 视觉化同伴（Canvas） 当预期接下来的问题涉及视觉内容时（模型、布局图、图表），提供 canvas 展示： - 使用 `canvas` 工具展示模型、图表、选项对比等视觉内容 - **每个问题决定是否用浏览器：** 用户看这个比读文字更好吗？ - **用 canvas：** 内容本身是视觉的——模型、线框图、布局对比、架构图、并排视觉设计 - **用文字：** 内容是文字的——需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策 关于 UI 主题的问题不自动是视觉问题。"在这个语境中个性意味着什么？"是概念问题——用文字。"哪种向导布局更好？"是视觉问题——用 canvas。 ## 执行检查表 每次开始创意工作前，确认： - [ ] 已探索项目上下文 - [ ] 已询问澄清问题（一次一个） - [ ] 已提出 2-3 种方案并说明推荐 - [ ] 主人已批准设计 - [ ] 设计文档已写完并 commit - [ ] 已做规格自审并修复问题 - [ ] 主人已审查书面规格 - [ ] 已调用 writing-plans 开始实现