brainstorming

将构想转化为设计

概述

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

首先了解当前项目背景，然后一次提出一个问题来完善构想。了解要构建的内容后，将设计分成篇幅较短的部分（200-300 个词）逐一呈现，并在每部分之后确认目前是否符合预期。

流程

了解构想：

• 首先查看当前项目状态（文件、文档、近期提交）
• 一次提出一个问题来完善构想
• 反馈工具：如果可以使用 mcp-feedback-enhanced（例如 ask_followup_question），请使用它来提出这些问题；如果不能，则使用标准聊天。
• 尽可能优先选择多选题，但也可以使用开放式问题
• 每条消息只问一个问题——如果某个主题需要进一步探讨，就拆分成多个问题
• 重点了解：目的、约束、成功标准

编写文档和规格说明：

• PRD（需求规格说明书）：编写标准化的需求文档，包含背景、用户流程、功能详细说明、验收标准。
• 项目介绍 (Project Introduction)：编写面向利益相关者或用户的项目愿景、核心价值、Roadmap。
• 特性说明 (Feature Docs)：针对具体模块编写交互细节与逻辑说明。

探索方案：

• 提出 2-3 种不同方案，并说明各自的利弊
• 以对话方式介绍选项，同时给出推荐方案和理由
• 首先介绍推荐方案并说明原因

呈现设计：

• 确信已了解要构建的内容后，呈现设计
• 将设计拆分为每部分 200-300 个词的章节
• 每部分之后询问目前是否符合预期
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果内容有不清楚之处，随时返回澄清

设计完成后

文档：

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

实施（如继续）：

• 询问：“准备好开始实施了吗？”
• 使用 superpowers:using-git-worktrees 创建隔离的工作区
• 使用 superpowers:writing-plans 制定详细的实施计划

核心原则

• 一次只问一个问题——不要一次提出多个问题让人应接不暇
• 优先选择多选题——条件允许时，多选题比开放式问题更容易回答
• 严格遵循 YAGNI 原则——从所有设计中删去不必要的功能
• 探索替代方案——确定方案前，始终提出 2-3 种方案
• 渐进式验证——分章节呈现设计，并逐一确认
• 灵活应变——遇到不清楚的地方时，返回澄清