brainstorming

将头脑风暴的想法转化为设计

概述

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

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

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

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

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

清单

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

1. 探索项目上下文 — 检查文件、文档和近期提交
2. 提出澄清问题 — 一次问一个问题，了解目的、约束条件和成功标准
3. 提出 2-3 种方案 — 说明权衡之处并给出推荐方案
4. 展示设计 — 根据复杂程度分节说明，并在每节之后征求用户批准
5. 编写设计文档 — 保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交
6. 过渡到实现阶段 — 调用 writing-plans 技能来制定实现计划

流程

digraph brainstorming {
    "Explore project context" [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];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "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" -> "Invoke writing-plans skill";
}

最终步骤是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴之后，唯一可以调用的技能是 writing-plans。

流程详解

理解想法：

• 先查看当前项目状态（文件、文档、近期提交）
• 一次提出一个问题，逐步完善想法
• 尽可能优先采用选择题，但开放式问题也可以
• 每条消息只问一个问题——如果一个主题需要进一步探讨，就拆分成多个问题
• 重点了解目的、约束条件和成功标准

探索方案：

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

展示设计：

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

设计完成后

文档：

• 将已确认的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
• 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
• 将设计文档提交到 git

实现：

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

核心原则

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