brainstorming

将创意转化为设计方案

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

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

在展示设计方案并获得用户批准之前，**不得**调用任何实现技能、编写任何代码、搭建任何项目骨架，也不得采取任何实现行动。此规则适用于**所有**项目，无论项目看起来多么简单。

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

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

检查清单

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

1. 了解项目背景 — 检查文件、文档和近期提交记录
2. 提供视觉辅助内容（如果主题涉及视觉问题）— 这应单独作为一条消息，不得与澄清问题合并。请参阅下方的“视觉辅助”部分。
3. 提出澄清问题 — 一次一个，了解目标、约束和成功标准
4. 提出 2-3 种方案 — 说明各自的权衡，并给出你的推荐方案
5. 展示设计方案 — 根据复杂程度分节呈现，并在每一节之后征求用户批准
6. 编写设计文档 — 保存到项目的规格说明/设计目录中（例如，ai-workspace/plans/YYYY-MM-DD-<topic>-design.md）。尊重用户对规格说明存放位置的偏好。
7. 自审规格说明 — 快速检查占位符、矛盾、歧义和范围（见下文）
8. 请用户审阅已编写的规格说明 — 在继续之前，请用户审阅规格说明文件
9. 转入实施阶段 — 调用 /blueprint 来创建实施计划

流程

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 /blueprint" [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 /blueprint" [label="approved"];
}

流程的最终状态是调用 /blueprint。 不得调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴之后唯一可以调用的技能是 /blueprint。

流程

理解想法：

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

探索方案：

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

呈现设计：

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

为隔离性和清晰性而设计：

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

在现有代码库中工作：

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

设计完成后

文档：

• 将经过验证的设计（规范）写入项目的规范／设计目录（例如，ai-workspace/plans/YYYY-MM-DD-<topic>-design.md）。遵循用户对规范存放位置的偏好。
• 如果可以使用 elements-of-style:writing-clearly-and-concisely 技能，请使用它
• 将设计文档提交到 git

规范自审： 写完规范文档后，以全新的视角审阅它：

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

在文档中直接修正任何问题。无需再次审阅——修正后继续即可。

用户审阅关卡： 通过规范审阅循环后，请用户审阅已编写的规范，再继续后续工作：

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

等待用户回复。如果用户要求修改，请按要求修改并重新运行规范审阅循环。只有在用户批准后才能继续。

实施：

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

核心原则

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

可视化辅助工具

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

提供辅助工具： 当你预计接下来的问题涉及可视内容（模型图、布局、图表）时，请征求用户同意，提供一次使用机会：

“我们接下来要处理的一些内容，用网页浏览器展示可能更容易说明。我可以在整个过程中制作模型图、图表、对比内容和其他可视化材料。这项功能仍处于早期阶段，可能会消耗较多 token。你想试试吗？（需要打开一个本地 URL）”

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

针对每个问题进行判断： 即使用户接受了，也要针对每个问题决定使用浏览器还是终端。判断标准：让用户亲眼看到内容，是否比阅读文字更容易理解？

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

关于 UI 主题的问题不一定就是视觉问题。“这里的个性是什么意思？”是一个概念问题——使用终端。“哪种向导布局更合适？”是一个视觉问题——使用浏览器。

如果用户同意使用辅助工具，请先阅读详细指南再继续。如果技能目录中有可视化辅助工具指南，请阅读该指南。