brainstorming

将创意构思成设计方案

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

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

在展示设计方案并获得用户批准之前，绝不要调用任何实施技能、编写代码、搭建项目脚手架或采取任何实施行动。无论项目看起来多么简单，这条规则都适用。

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

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

检查清单

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

1. 了解项目背景 — 检查文件、文档和近期提交
2. 提供视觉辅助（如果主题涉及视觉问题）— 单独发送消息，不要与澄清问题合并。请参阅下文的“视觉辅助”部分。
3. 提出澄清问题 — 一次一个，了解目的、约束条件和成功标准
4. 提出 2-3 种方案 — 说明各自的权衡，并给出你的建议
5. 展示设计方案 — 根据复杂程度分节说明，并在每节后征求用户批准
6. 编写设计文档 — 保存到 docs/specs/YYYY-MM-DD-<topic>-design.md
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];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [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" -> "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?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

最终状态是调用 writing-plans。 不要调用 designing-frontend-interfaces、building-mcp-servers 或任何其他实施技能。头脑风暴之后，唯一可以调用的技能是 writing-plans。

流程

理解构想：

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

探索方案：

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

呈现设计：

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

当项目包含用户界面时：

规格说明中有两项内容很容易遗漏，而以后补上代价高昂，因为二者都涉及结构：

• 美学方向。 不要只写“简洁现代”，而要指定一个有现实参照的具体方向。designing-frontend-interfaces/references/aesthetic-directions.md 中有可供选择的目录。在实施阶段才决定，意味着最终会由默认设置决定。
• 状态覆盖。 对于每个屏幕：首次使用且没有数据的用户会看到什么、失败时是什么样子、网络连接缓慢时会发生什么？designing-user-experience 中包含完整的状态矩阵。这些是需求，而非润色；遗漏这些内容的规格说明，也会导致实现中遗漏这些状态。

在澄清问题时询问这两项。不要调用实施技能——可以阅读参考文件中的目录，但最终状态仍然是编写计划。

通过隔离和清晰性进行设计：

• 将系统拆分为更小的单元，每个单元都有明确的用途，通过定义良好的接口通信，并且可以独立理解和测试
• 对于每个单元，你都应该能回答：它做什么、如何使用，以及依赖什么？
• 不阅读单元内部实现，也能理解它的作用吗？能否在不影响使用方的情况下修改其内部实现？如果不能，就需要重新划分边界。
• 更小且边界清晰的单元也更便于你开展工作——一次能在上下文中掌握的代码越少，推理效果就越好；文件职责越集中，修改就越可靠。文件变得很大时，往往意味着它承担了过多职责。

在现有代码库中工作：

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

设计完成后

文档：

• 将已验证的设计（规格说明）写入 docs/specs/YYYY-MM-DD-<topic>-design.md
  • （用户对规格说明位置的偏好优先于此默认设置）

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

1. 占位符检查： 是否有“待定”、“TODO”、未完成的部分或含糊的需求？请修正。
2. 内部一致性： 是否有章节相互矛盾？架构是否与功能描述一致？
3. 范围检查： 这是否足够聚焦，能作为单个实现计划？还是需要拆分？
4. 歧义检查： 是否有任何需求可能被解读为两种不同的意思？如果有，请选定一种并明确说明。

直接修正发现的问题。无需再次审查——修正后继续即可。

用户审阅关卡： 规格说明通过审查循环后，请先让用户审阅已编写的规格说明，再继续：

"规格说明已写入 <path>。请审阅，并告知我在开始编写实现计划前是否需要做任何更改。"

等待用户回复。如果用户要求更改，请完成更改并重新运行规格说明审查循环。仅在用户批准后继续。

实现：

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

核心原则

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

视觉辅助工具

一种基于浏览器的辅助工具，可在头脑风暴期间展示模型图、图表和视觉选项。它是一种工具，而非模式。接受使用该辅助工具意味着可以在适合视觉呈现的问题中使用它；这并不意味着每个问题都要通过浏览器处理。

提供视觉辅助工具： 如果预计接下来会涉及视觉内容（模型图、布局、图表），请征求一次同意：

"我们接下来讨论的某些内容，可能通过网页浏览器展示会更容易理解。我可以在过程中制作模型图、图表、对比和其他视觉内容。这项功能仍处于早期阶段，可能会消耗较多 token。想试试吗？（需要打开本地 URL）"

此邀请必须单独作为一条消息发送。 不要将其与澄清问题、背景摘要或任何其他内容合并。消息中只能包含上述邀请，不得包含其他内容。等待用户回复后再继续。如果用户拒绝，则继续进行纯文本头脑风暴。

按问题决定： 即使用户接受了，也要针对每个问题判断应使用浏览器还是终端。判断标准：用户通过观看是否会比阅读理解得更好？

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

涉及 UI 的问题不一定就是视觉问题。“在此情境中，个性是什么意思？”是概念问题，应使用终端。“哪种向导布局更合适？”是视觉问题，应使用浏览器。

如果用户同意使用视觉辅助工具，请在继续之前阅读详细指南： skills/brainstorming/visual-companion.md