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 种方案
• 增量验证 — 展示设计方案，并在继续之前获得批准
• 保持灵活 — 遇到不清楚的地方时，回头澄清