brainstorming

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

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

首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。

反模式："这个太简单了，不需要设计"

每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。

检查清单

你必须为以下每个条目创建任务，并按顺序完成：

1. 探索项目上下文 — 检查文件、文档、最近的 commit
2. 提供视觉伴侣（如果主题涉及视觉问题）— 这是一条独立的消息，不要与澄清问题合并。参见下方的"视觉伴侣"部分。
3. 提出澄清问题 — 每次一个，了解目的/约束/成功标准
4. 提出 2-3 种方案 — 附带权衡分析和你的推荐
5. 展示设计 — 按复杂度分节展示，每节展示后获得用户批准
6. 编写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并 commit
7. 规格自检 — 快速内联检查占位符、矛盾、模糊性、范围（详见下方）
8. 用户审查书面规格 — 在继续之前请用户审查规格文件
9. 过渡到实现 — 调用 writing-plans 技能创建实现计划

流程图

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "有视觉相关问题?" [shape=diamond];
    "提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box];
    "提出澄清问题" [shape=box];
    "提出 2-3 种方案" [shape=box];
    "分节展示设计" [shape=box];
    "用户批准设计?" [shape=diamond];
    "编写设计文档" [shape=box];
    "规格自检\n（内联修复）" [shape=box];
    "用户审查规格?" [shape=diamond];
    "调用 writing-plans 技能" [shape=doublecircle];

    "探索项目上下文" -> "有视觉相关问题?";
    "有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"];
    "有视觉相关问题?" -> "提出澄清问题" [label="否"];
    "提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题";
    "提出澄清问题" -> "提出 2-3 种方案";
    "提出 2-3 种方案" -> "分节展示设计";
    "分节展示设计" -> "用户批准设计?";
    "用户批准设计?" -> "分节展示设计" [label="否，修改"];
    "用户批准设计?" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规格自检\n（内联修复）";
    "规格自检\n（内联修复）" -> "用户审查规格?";
    "用户审查规格?" -> "编写设计文档" [label="要求修改"];
    "用户审查规格?" -> "调用 writing-plans 技能" [label="批准"];
}

终止状态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴之后你唯一要调用的技能是 writing-plans。

流程详述

理解想法：

• 首先查看当前项目状态（文件、文档、最近的 commit）
• 在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如"构建一个包含聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。
• 如果项目规模过大，单个规格说明无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的规格 → 计划 → 实现周期。
• 对于范围适当的项目，每次提一个问题来完善想法
• 尽量使用选择题，开放式问题也可以
• 每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题
• 重点理解：目的、约束、成功标准