将创意构思为设计

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

首先了解当前项目的上下文，然后一次提出一个问题来完善想法。一旦您理解了要构建的内容，就呈现设计并获得用户的批准。

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

每个项目都要经历这个过程。待办事项列表、单一功能工具、配置更改——所有这些都是如此。“简单”的项目正是未经审视的假设导致最多浪费工作的地方。设计可以很短（对于真正简单的项目，几句话即可），但您必须呈现它并获得批准。

检查清单

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

1. 探索项目上下文 — 检查文件、文档、最近的提交
2. 提供视觉伴侣（如果主题将涉及视觉问题）— 这是独立的一条消息，不混合澄清问题。请参阅下面的“视觉伴侣”部分。
3. 提出澄清性问题 — 一次一个，理解目的/约束/成功标准
4. 提出 2-3 种方法 — 说明权衡利弊和您的建议
5. 呈现设计 — 根据复杂性分节呈现，在每节后获得用户批准
6. 编写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md 并提交
7. 规格审查循环 — 分派规范文档审查子代理；修复问题并重新分派，直到获得批准（最多 5 次迭代，然后提交给人工处理）
8. 用户审查书面规格 — 在继续之前，要求用户审查规格文件
9. 过渡到实施 — 调用 writing-plans 技能以创建实施计划

流程

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "后续涉及视觉问题？" [shape=diamond];
    "提供视觉伴侣\n(独立消息，不含其他内容)" [shape=box];
    "提出澄清性问题" [shape=box];
    "提出 2-3 种方法" [shape=box];
    "分节呈现设计" [shape=box];
    "用户批准设计？" [shape=diamond];
    "编写设计文档" [shape=box];
    "规格审查循环" [shape=box];
    "规格审查通过？" [shape=diamond];
    "用户审查规格？" [shape=diamond];
    "调用 writing-plans 技能" [shape=doublecircle];

    "探索项目上下文" -> "后续涉及视觉问题？";
    "后续涉及视觉问题？" -> "提供视觉伴侣\n(独立消息，不含其他内容)" [label="是"];
    "后续涉及视觉问题？" -> "提出澄清性问题" [label="否"];
    "提供视觉伴侣\n(独立消息，不含其他内容)" -> "提出澄清性问题";
    "提出澄清性问题" -> "提出 2-3 种方法";
    "提出 2-3 种方法" -> "分节呈现设计";
    "分节呈现设计" -> "用户批准设计？";
    "用户批准设计？" -> "分节呈现设计" [label="否，修订"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规格审查循环";
    "规格审查循环" -> "规格审查通过？";
    "规格审查通过？" -> "规格审查循环" [label="发现问题，\n修复并重新分派"];
    "规格审查通过？" -> "用户审查规格？" [label="已批准"];
    "用户审查规格？" -> "编写设计文档" [label="请求更改"];
    "用户审查规格？" -> "调用 writing-plans 技能" [label="已批准"];
}

最终状态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实施技能。构思之后唯一调用的技能是 writing-plans。

流程

理解创意：

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

探索方法：

• 提出 2-3 种不同的方法，并说明权衡利弊
• 以对话的方式呈现选项，说明您的建议和理由
• 从您推荐的选项开始，并解释原因

呈现设计：

• 一旦您相信理解了要构建的内容，就呈现设计
• 根据复杂性缩放每一节的篇幅：如果简单明了，用几句话；如果微妙复杂，可用 200-300 字
• 在每一节之后询问用户看起来是否正确
• 涵盖：架构、组件、数据流、错误处理、测试
• 准备好如果某些内容不合理，返回并澄清

为隔离和清晰而设计：

• 将系统分解为较小的单元，每个单元有一个清晰的目的，通过定义良好的接口进行通信，并且可以独立理解和测试
• 对于每个单元，您应该能够回答：它做什么，如何使用它，它依赖什么？
• 有人能在不阅读其内部实现的情况下理解一个单元做什么吗？您能否在不破坏使用方的情况下更改其内部实现？如果不能，边界需要改进。
• 较小且边界清晰的单元也更易于您处理——您能更好地推理一次可以容纳在上下文中的代码，并且当文件专注时，您的编辑更可靠。当文件变得庞大时，这通常表明它做得太多。

在现有代码库中工作：

• 在提出更改之前，探索现有结构。遵循现有模式。
• 如果现有代码存在问题影响了工作（例如，文件变得过大、边界不清、职责混乱），请将有针对性的改进作为设计的一部分——这是优秀的开发者在处理代码时会采用的方式。
• 不要提出无关的重构。专注于服务于当前目标的内容。

设计之后

文档：

• 将已验证的设计（规格）写入 docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md
  • （用户对规格位置的偏好会覆盖此默认值）
• 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
• 将设计文档提交到 git

规格审查循环：
编写规格文档后：

1. 分派规范文档审查子代理（参见 spec-document-reviewer-prompt.md）
2. 如果发现问题：修复，重新分派，重复直到获得批准
3. 如果循环超过 5 次迭代，提交给人工指导

用户审查关卡：
在规格审查循环通过后，请用户在继续之前审查书面规格：

“规格已编写并提交到 <路径>。请审阅，并告知是否要在我们开始编写实施计划之前进行任何更改。”

等待用户的回应。如果他们要求更改，进行修改并重新运行规格审查循环。仅在用户批准后继续。

实施：

• 调用 writing-plans 技能以创建详细的实施计划
• 不要调用任何其他技能。writing-plans 是下一步。

关键原则

• 一次一个问题 – 不要用多个问题使用户不知所措
• 优先使用多项选择 – 在可能的情况下，比开放式问题更容易回答
• 严格遵循“你不需要它”原则 – 从所有设计中移除不必要的功能
• 探索替代方案 – 在确定之前，始终提出 2-3 种方法
• 增量验证 – 呈现设计，在继续之前获得批准
• 保持灵活 – 当某些内容不合理时，返回并澄清

视觉伴侣

一个基于浏览器的伴侣，用于在构思过程中展示模拟图、图表和视觉选项。作为一个工具提供——不是一种模式。接受伴侣意味着它可以用于需要视觉处理的问题；这并不意味着每个问题都要通过浏览器。

提供伴侣：当您预计接下来的问题将涉及视觉内容（模拟图、布局、图表）时，提供一次以征得同意：

“我们正在处理的一些事情，如果我能通过网络浏览器向您展示，可能会更容易解释。我可以边进行边准备模拟图、图表、对比和其他视觉材料。这个功能还比较新，并且可能消耗较多令牌。想试试吗？（需要打开一个本地 URL）”

此邀请必须是单独的一条消息。 不要将其与澄清性问题、上下文摘要或任何其他内容混合。该消息应仅包含上述邀请，别无其他。等待用户的回应后再继续。如果他们拒绝，则继续进行纯文本的构思。

每个问题的决定：即使在用户接受之后，也要针对每个问题决定是使用浏览器还是终端。测试标准是：用户通过观看会比通过阅读能更好地理解这个问题吗？

• 使用浏览器 处理属于视觉的内容——模拟图、线框图、布局比较、架构图、并排视觉设计
• 使用终端 处理文本内容——需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策

关于 UI 主题的问题并不自动是视觉问题。“个性在这个上下文中意味着什么？”是一个概念性问题——使用终端。“哪个向导布局效果更好？”是一个视觉问题——使用浏览器。

如果他们同意使用伴侣，在继续之前请阅读详细指南：
skills/brainstorming/visual-companion.md