brainstorming

将创意构思转化为设计

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

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

<HARD-GATE>
在呈现设计并获得用户批准之前，不得调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于每个项目，无论其看似多么简单。
</HARD-GATE>

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

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

检查清单

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

1. 探索项目上下文 — 检查文件、文档、最近的提交
2. 提供视觉伴侣（如果主题涉及视觉问题）— 这作为单独的消息，不与澄清问题合并。请参阅下面的视觉伴侣部分。
3. 提出澄清问题 — 一次一个，理解目的/约束/成功标准
4. 提出2-3种方案 — 附带权衡和你的推荐
5. 呈现设计 — 按复杂度缩放各部分，每部分后获得用户批准
6. 编写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
7. 规格自审 — 快速内联检查占位符、矛盾、歧义、范围（见下文）
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];
    "规格自审\n（内联修复）" [shape=box];
    "用户审查规格？" [shape=diamond];
    "调用 writing-plans 技能" [shape=doublecircle];

    "探索项目上下文" -> "是否有视觉问题？";
    "是否有视觉问题？" -> "提供视觉伴侣\n（单独消息，无其他内容）" [label="是"];
    "是否有视觉问题？" -> "提出澄清问题" [label="否"];
    "提供视觉伴侣\n（单独消息，无其他内容）" -> "提出澄清问题";
    "提出澄清问题" -> "提出2-3种方案";
    "提出2-3种方案" -> "呈现设计各部分";
    "呈现设计各部分" -> "用户批准设计？";
    "用户批准设计？" -> "呈现设计各部分" [label="否，修改"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规格自审\n（内联修复）";
    "规格自审\n（内联修复）" -> "用户审查规格？";
    "用户审查规格？" -> "编写设计文档" [label="要求更改"];
    "用户审查规格？" -> "调用 writing-plans 技能" [label="已批准"];
}

最终状态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴后你唯一调用的技能是 writing-plans。

流程

理解想法：

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

探索方案：

• 提出2-3种不同的方案，附带权衡
• 以对话方式呈现选项，附上你的推荐和理由
• 首先推荐你的首选选项并解释原因

呈现设计：

• 一旦你认为理解了要构建的内容，呈现设计
• 按复杂度缩放每个部分：如果简单则几句话，如果复杂则最多200-300字
• 每部分后询问是否看起来正确
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果某些内容不合理，准备好返回并澄清

为隔离和清晰而设计：

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

在现有代码库中工作：

• 在提出更改之前探索当前结构。遵循现有模式。
• 如果现有代码存在问题影响工作（例如，文件变得太大、边界不清晰、职责混乱），将有针对性的改进作为设计的一部分——就像优秀开发者在他们工作的代码中改进代码一样。
• 不要提出不相关的重构。专注于服务于当前目标。

设计之后

文档：

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

规格自审：
编写规格文档后，用新的眼光审视它：

1. 占位符扫描： 是否有“待定”、“TODO”、不完整的部分或模糊的需求？修复它们。
2. 内部一致性： 各部分之间是否有矛盾？架构是否与功能描述匹配？
3. 范围检查： 是否足够聚焦以适合单个实现计划，还是需要分解？
4. 歧义检查： 是否有任何需求可以有两种不同的解释？如果是，选择一种并明确说明。

内联修复任何问题。无需重新审查——只需修复并继续。

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

“规格已编写并提交到 <path>。请审查，并告知是否希望在开始编写实现计划之前进行任何更改。”

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

实现：

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

关键原则

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

视觉伴侣

一个基于浏览器的伴侣，用于在头脑风暴期间展示模型、图表和视觉选项。作为工具提供——不是模式。接受伴侣意味着它可用于受益于视觉处理的问题；并不意味着每个问题都通过浏览器进行。

提供伴侣： 当你预计即将提出的问题将涉及视觉内容（模型、布局、图表）时，提供一次以获得同意：

“我们正在处理的一些内容如果我能通过网页浏览器展示给你看，可能会更容易解释。我可以随着进展制作模型、图表、对比和其他视觉内容。这个功能还很新，可能消耗较多令牌。想试试吗？（需要打开本地URL）”

此提供必须是单独的消息。 不要将其与澄清问题、上下文摘要或任何其他内容合并。消息应仅包含上述提供，没有其他内容。在继续之前等待用户响应。如果他们拒绝，则继续纯文本头脑风暴。

每个问题的决策： 即使在接受后，也要为每个问题决定是使用浏览器还是终端。测试标准：用户通过看到它比阅读它理解得更好吗？

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

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

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