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 种方案
• 逐步验证 — 展示设计方案，并在继续之前获得批准
• 保持灵活 — 如果有内容不清楚，就回过头来澄清