brainstorming

将创意构思成设计方案

通过自然的协作式对话，帮助将创意转化为完整的设计方案和规格说明。

先了解当前项目背景，然后一次提出一个问题，逐步完善创意。了解要构建的内容后，展示设计方案并征得用户批准。

在以下条件全部满足之前，禁止编写任何代码、搭建任何项目脚手架、调用任何实现技能或采取任何实现行动：已展示并获批设计方案、已编写并提交规格说明、用户已审阅书面规格说明，并且已调用 writing-plans 技能。用户在聊天中批准设计方案（“看起来不错，继续”）只能完成清单中的下一项——这并不代表可以开始实施。无论项目看起来多么简单，这条规定都适用。

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

每个项目都必须遵循这一流程。待办事项列表、单函数工具、配置更改——无一例外。“简单”的项目最容易因为未经审视的假设而造成大量无谓工作。设计方案可以很短（对于确实简单的项目，几句话即可），但你必须展示设计方案并获得批准。

何时不适用

• 调试／修复回归问题——使用 rubypowers:systematic-debugging。如果修复最终改变了预期行为，再回到这里。
• 执行已获批的计划——使用 rubypowers:executing-plans 或 subagent-driven-development。
• 纯研究或提问——既然不涉及实现，就没有需要设计的内容。

检查清单

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

1. 探索项目背景——检查文件、文档和近期提交
2. 提供可视化辅助（如果主题涉及视觉问题）——这必须作为单独的消息发送，不能与澄清问题合并。请参阅下文的“可视化辅助”部分。
3. 提出澄清问题——一次一个，了解目的、约束和成功标准
4. 提出 2-3 种方案——说明各自的权衡，并给出你的建议
5. 展示设计方案——根据复杂程度分节说明，并在每节之后征得用户批准
6. 完成设计文档——将持续完善的草稿（见“边做边保存”）整理为最终版本，放入选定的规格文件夹，其中包括决策日志，并提交。新项目使用 docs/rubypowers/specs/；如果 docs/superpowers/specs/ 已存在，则将草稿和最终规格说明都保留在那里。
7. 规格说明自查——快速检查是否存在占位符、矛盾、歧义或范围问题（见下文）
8. 用户审阅书面规格说明——继续之前，请用户审阅规格文件
9. 转入实施阶段——调用 writing-plans 技能来创建实施计划

流程

digraph brainstorming {
    "Explore project context" [shape=box];
    "Visual questions ahead?" [shape=diamond];
    "Offer Visual Companion\n(own message, no other content)" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Create DRAFT spec\n(append decisions as they land)" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Finalize design doc\n(promote DRAFT, add Decisions)" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Visual questions ahead?";
    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Create DRAFT spec\n(append decisions as they land)";
    "Create DRAFT spec\n(append decisions as they land)" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Ask clarifying questions" [label="no, misunderstood the goal"];
    "User approves design?" -> "Finalize design doc\n(promote DRAFT, add Decisions)" [label="yes"];
    "Finalize design doc\n(promote DRAFT, add Decisions)" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Finalize design doc\n(promote DRAFT, add Decisions)" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

最终步骤是调用 writing-plans。 禁止调用 frontend-design、mcp-builder 或任何其他实现技能。构思完成后，唯一可以调用的技能是 writing-plans。

流程

理解想法：

• 先查看当前项目状态（文件、文档、近期提交）
• 在提出详细问题之前，先评估范围：如果请求描述了多个彼此独立的子系统（例如“构建一个包含聊天、文件存储、计费和分析功能的平台”），请立即指出。不要花时间询问细节来完善一个需要先拆分的项目。
• 如果项目对于单份规格说明来说过于庞大，请帮助用户拆分为多个子项目：哪些部分彼此独立、它们之间有何关联、应按什么顺序构建？然后按照常规设计流程，为第一个子项目集思广益。每个子项目都有自己的规格说明 → 计划 → 实施周期。
• 对于范围合适的项目，每次只问一个问题，逐步明确想法
• 尽可能优先使用选择题，但开放式问题也可以。如果有 AskUserQuestion 工具，请使用它呈现选项。
• 默认每条消息只问一个问题——如果某个主题需要进一步探讨，就拆分成多个问题
• 例外：如果问题确实彼此独立（一个问题的答案不会影响另一个问题），可以在一次 AskUserQuestion 调用中批量提出最多 4 个选择题。尤其适用于用户时间紧迫的情况。相互依赖的问题绝不批量提出。
• 重点了解：目的、约束、成功标准

随进展持续记录：

• 一旦开始形成实际决策，就立即创建规格说明文件草稿（顶部标注 Status: DRAFT），并在每项决策确定后将其补充进去
• 聊天记录不能作为存储——会话崩溃、上下文被压缩或中断，都不应导致头脑风暴的状态丢失。草稿文件应供后续会话继续使用。

探索方案：

• 提出 2-3 种不同方案，并说明各自的权衡
• 以对话式的方式介绍选项，并给出你的推荐及理由
• 先介绍你推荐的方案，并解释原因

呈现设计：

• 确信自己已理解要构建的内容后，呈现设计
• 根据复杂程度调整每个部分的篇幅：简单的内容用几句话，复杂的内容最多 200-300 词
• 每介绍完一个部分，就询问目前看来是否合适
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果有些内容不合理，要准备好回头澄清

设计时注重隔离与清晰：

• 将系统拆分为更小的单元，每个单元都有明确的用途，通过定义清晰的接口进行通信，并且能够独立理解和测试
• 对于每个单元，你都应该能回答：它做什么、如何使用它、它依赖什么？
• 不看内部实现，也能理解一个单元的作用吗？修改内部实现时，能不影响使用方吗？如果不能，就需要重新划分边界。
• 较小且边界清晰的单元也更便于你处理——你更擅长推理能够一次性纳入上下文的代码，而且文件职责越聚焦，修改就越可靠。文件变得很大时，往往说明它承担了过多职责。

在现有代码库中工作：

• 提出更改建议之前，先了解当前结构。遵循现有模式。
• 如果现有代码中存在影响当前工作的缺陷（例如文件过大、边界不清晰、职责纠缠），请将针对性的改进纳入设计，就像优秀的开发者会改进自己正在处理的代码一样。
• 不要提出无关的重构。聚焦于服务当前目标的内容。

设计之后

文档：

• 新项目将草稿和最终规格说明保存到 docs/rubypowers/specs/。如果 docs/superpowers/specs/ 已存在，则将该旧文件夹用于草稿、定稿、最终保存和任何审阅者说明。整个工作流中始终使用选定的实际文件夹；不要将同一项目的规格说明分散到两个位置。
• 将正在编写的草稿定稿为 <selected specs folder>/YYYY-MM-DD-<topic>-design.md（移除 DRAFT 标题）
  • （用户对规格说明位置的偏好优先于此默认设置）
• 规格说明 MUST 包含 ## Decisions 部分：列出头脑风暴中用户明确作出的每项决定，原文照录或近乎照录，并为每项决定附上一行理由。后续规格说明审阅和计划一致性检查都以此部分为依据。
• 如果可用，请使用 elements-of-style:writing-clearly-and-concisely skill
• 将设计文档提交到 git

规格说明自审： 写完规格说明文档后，以全新的视角审阅：

1. 占位符扫描： 是否有任何 “TBD”、“TODO”、未完成的部分或含糊的需求？修正它们。
2. 内部一致性： 各部分之间是否存在矛盾？架构是否与功能描述一致？
3. 范围检查： 内容是否足够聚焦，可以制定单个实施计划？还是需要拆分？
4. 歧义检查： 是否有任何需求可能被理解为两种不同的意思？如果有，选定一种并明确写出。

直接修正发现的问题。无需重新审阅；修正后继续即可。

对于复杂或高风险的规格说明，还应使用此 skill 同一目录下的 spec-document-reviewer-prompt.md 模板，派遣一名具有全新上下文的审阅子 Agent。小型规格说明无需执行此步骤；行内检查已足够。

用户审阅关卡： 规格说明审阅流程通过后，请用户审阅已撰写的规格说明，然后再继续：

“规格说明已撰写并提交到 <path>。请审阅，并告知我在开始编写实施计划前是否需要进行任何修改。”

等待用户回复。如果用户要求修改，请完成修改并重新运行规格说明审阅流程。只有用户批准后才能继续。

实施：

• 调用 writing-plans skill，创建详细的实施计划
• 不要调用任何其他 skill。下一步必须是 writing-plans。

核心原则

• 一次只问一个问题——不要用多个问题让用户应接不暇
• 优先使用选择题——条件允许时，选择题比开放式问题更容易回答
• 严格遵循 YAGNI 原则——从所有设计中移除不必要的功能
• 探索替代方案——确定方案前，始终提出 2～3 种方案
• 增量验证——展示设计，并在继续前获得批准
• 保持灵活——遇到不合理之处时，返回并澄清

合理化借口对照表

借口	事实
“用户已经明确告诉我他们想要什么”	用户给出的是一个解决方案，而不是其中隐含的开放决策。用 3 句话描述设计，再征求一句话的批准，就能在几秒内把这些决策明确出来。
“用户说可以跳过设计流程”	应缩短流程，而不是跳过：采用最简短的设计，并只发送一条审批消息。速度来自简洁，而不是绕过关卡。
“用户已经在聊天中批准了，所以我可以开始编码了”	聊天中的批准只完成了一项检查。撰写规格说明 → 提交 → 用户审阅书面文件 → writing-plans，这些步骤仍必须完成。
“文档可以省略，内容很小”	已提交的规格说明是计划和后续会话的依据。聊天记录会消失；用户批准的是聊天中的简介，而不是经过审阅的规格说明。
“我把设计和代码一起展示，节省时间”	这会破坏关卡的作用——错误假设必须在开始工作前发现，否则时间已经浪费了。

危险信号 — 停止

• 在没有已提交规范的情况下准备编写代码
• 把“开始吧”/“看起来不错”当作实施许可
• 计划在编写代码之后再补写规范，“记录我做了什么”
• 未展示并获批设计，就从想法直接跳到编写计划

以上任何情况都意味着：返回检查清单，完成当前事项。

视觉辅助工具

一个基于浏览器的辅助工具，可在头脑风暴期间展示模型图、图表和视觉选项。它是一种工具，而不是模式——接受它并不意味着每个问题都会通过浏览器处理。

提供辅助工具： 如果你预料到会有视觉相关问题（模型图、布局、图表），请征求一次同意，提供该工具：

“我们正在讨论的某些内容，如果能在网页浏览器中展示给你，可能会更容易解释。我可以在讨论过程中制作模型图、图表、对比图和其他视觉内容。此功能仍是新功能，可能会消耗较多 token。想试试吗？（需要打开本地 URL）”

此提议必须单独作为一条消息发送——不要附带其他内容，并等待对方回复。如果对方拒绝，则仅通过文本继续。

接受后，逐个问题判断： 仅当用户通过观看能更好地理解问题时，才使用浏览器（模型图、布局对比、图表）；所有文本内容（需求、权衡、范围）都使用终端。涉及 UI 的问题并不一定就是视觉问题。

如果对方接受，请先阅读详细指南再继续：skills/brainstorming/visual-companion.md