brainstorming

将创意头脑风暴转化为设计

目的

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

何时使用

在以下情况下使用此技能：

• 请求涉及创建或更改行为／功能
• 需求模糊或不完整
• 实现前需要分析权衡
• 编码前必须先审批设计文档

进度跟踪

在每个主要阶段开始前显示进度指示器：

[████░░░░░░░░░░░░░░░░] 20% — Phase 1/5: Exploring Project Context
[████████░░░░░░░░░░░░] 40% — Phase 2/5: Clarifying Requirements
[████████████░░░░░░░░] 60% — Phase 3/5: Proposing Approaches
[████████████████░░░░] 80% — Phase 4/5: Presenting Design
[████████████████████] 100% — Phase 5/5: Writing Design Doc

工作流

1. 探索项目背景
2. 一次提出一个澄清问题
3. 提出 2-3 种方案并分析权衡
4. 分段展示设计并征求批准
5. 保存设计文档并移交给 writing-plans

概述

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

在展示设计并获得用户批准之前，不得调用任何实现技能、编写任何代码、搭建任何项目脚手架或采取任何实现行动。此要求适用于 EVERY 个项目，无论其看起来多么简单。

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

每个项目都必须经过此流程。待办事项列表、单函数工具、配置更改——无一例外。“简单”项目最容易因未经审视的假设而造成大量返工。设计可以很简短（真正简单的项目只需几句话），但你 MUST 展示设计并征得批准。

检查清单

你 MUST 为以下每项创建一个任务，并按顺序完成：

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 种方法
• 增量验证 - 展示设计并获得批准后，再继续下一步
• 保持灵活 - 遇到不合理之处时，回头澄清

关键规则

• 在用户批准设计前，绝不开始实施。
• 绝不跳过至少 2 种方案之间的权衡讨论。
• 绝不在头脑风暴过程中直接调用实施技能（只移交给 writing-plans）。

使用示例

1. “使用头脑风暴，在开始编写代码前确定仪表板的重新设计方案。”
2. “使用头脑风暴，明确 API 的需求和限制。”
3. “使用头脑风暴，比较新功能的架构选项。”