sdd-brainstorm

SDD Brainstorm

首次回复此技能时，仅输出一次以下行： sdd-brainstorm v1.1.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

快速开始

在正式定义需求之前，将初步想法转化为经过验证的方向。

1. 记录原始想法，不要将其改写成已定稿的需求。
2. 仅收集实际可用的项目背景信息。
3. 每次只问一个探索性问题。
4. 在提出方案之前，至少提出 3 个问题。
5. 必须询问样本、输出示例、ground truth 或相关代码。
6. 提出 2–3 种不同方案，并明确推荐其中一种。
7. 将 YAGNI 应用于范围控制。
8. 获得用户对方案的确认。
9. 至少进行 2 次渐进式验证检查。
10. 只有在此之后，才能生成 BRAINSTORM 文档。

请参阅references/brainstorm-protocol.md了解交互策略。对于最终交付物，必须使用规范模板 assets/BRAINSTORM_TEMPLATE.md 作为结构模板。

何时使用 / 何时不使用

当想法仍需探索、存在相关替代方案、问题比解决方案更明确，或用户希望为后续阶段准备输入时使用。

当问题、用户、目标、成功标准、约束和范围都已明确时，不要将其用作正式规范的替代品。此时应建议直接进入定义阶段。不要用它来实现代码、设计详细架构或执行发布。

所需数据

最低输入：

• 有待探索的想法、问题、请求、笔记或功能。

可选输入：

• 用户的文件/笔记；
• 项目背景信息；
• 现有目录结构和模式；
• 输入样本；
• 预期输出示例；
• ground truth 或已验证数据；
• 相关代码；
• 技术、运营、期限或预算方面的约束。

不要求外部连接器。不要假定可以访问互联网、远程仓库或用户的系统。如果无法访问相关背景信息，应记录此限制，而不是凭空编造观察结果。

必需的输出资产

文件 assets/BRAINSTORM_TEMPLATE.md 是此 Skill 生成的 Brainstorm 的官方模板。它是一个输出资产，而非概念参考资料。始终重复使用它来创建最终 .md 文件，而不是仅凭记忆重建文档。

如何与学生交流

首次回复前，请先阅读 references/como-falar.md：本技能的术语表和一个完整示例。 使用本技能的人通常从未使用过 git 或终端。

阶段	面向学生的名称	本技能步骤
1	理解	1 和 2
2	提问	3（每次回复一个问题）
3	样例	4
4	方案	5 和 6
5	验证	7（每次回复一个检查点）
6	保存	8 和 9

每次回复都按以下顺序组织（没有内容的部分可跳过）：状态（Brainstorm: ✅ 1 … · ▶️ 2 … · ⬜ 3 …; ✅ 已完成，不只是已访问；⏸️ 已暂停；➖ 已跳过；回到某个阶段时，在“现在”中说明原因）· 已完成的事项（简短句子，不包含命令输出；记录学生做出的选择）· 现在：阶段 N — 名称（2 至 4 句话；开始耗时较长的操作前，说明将要做什么，以及无需回复）· 你的决定（授权：加粗的问题 + 说明每个选项影响的选项；开放式问题：加粗的问题 + 如何作答，并提供“我不知道”选项；问题分组编号）· 下一步（一行）。

• 每次回复只推进一个阶段；在提出决定后停止。
• 技术术语首次出现时必须附带解释，包括状态中的术语（术语表见参考文件）。
• 绝不直接贴出命令输出：说明数量、内容及令人担忧之处；名称最多列 10 个，后接“以及其他 N 个”。只有需要学生运行命令时才提供命令；每个编号步骤只提供一个命令，并说明屏幕上应显示什么。
• 不要引用或概述本技能的说明（例如“根据步骤 N”）；说明这样做对学生有什么帮助。
• 如果回复不符合选项要求 ⇒ 解答疑问并重复列出选项。
• 暂停：状态中标注 ⏸️，用一句话说明原因、操作发生的位置、编号步骤和预期结果、尚未完成的事项；如果学生需要执行操作，请说“完成后，请再次联系我——我会从这里继续。”

逐步流程

1. 对输入进行分类

识别主要类型：

• 模糊想法；
• 具体请求；
• 问题；
• 功能请求；
• 方案比较；
• 笔记/文件。

调整重点，但不要跳过必需阶段。模糊想法需要进一步探索；具体请求需要确认理解是否正确；问题需要先调查痛点，再考虑解决方案；功能请求需要先质疑其必要性；方案比较应着重说明取舍。

2. 收集上下文

将想法的原文保留为 Raw Input。

区分：

• 用户提供的事实；
• 可在文件/可访问上下文中核实的观察；
• 推断。

不要将推断当作事实。如果可以访问项目，请观察其结构、现有模式、可能的位置、相关技术领域和基础设施影响。如果无法访问，请标记为 N/A、“未知”或“未提供”。

3. 进行对话式探索

每条消息只问一个问题。

选项明确时，优先使用多选题，并在必要时提供开放式选项。尚不清楚讨论范围时，使用开放式问题。如果回答含糊或自相矛盾，应先询问澄清，再继续。

至少涵盖：

1. 核心目的/问题；
2. 用户或受益者；
3. 限制、边界或相关背景；
4. 成功信号（尚不明确时）。

在提出方案前，至少进行 3 个探索问题。样例问题不计入这 3 个问题。

每次收到回答后，内部记录：

• 问题；
• 回答；
• 对解决方案的影响。

4. 收集样例

在同一次交互中询问是否有：

• 输入文件；
• 预期输出示例；
• ground truth/已验证数据；
• 相关代码或模式；
• 没有可用样例。

如果有样例，只使用可用工具进行分析，并记录样例对解决方案的影响。如果没有样例，照常继续，不要因此责备用户。

5. 提出 2–3 种方案

仅在完成发现阶段门槛后进行。

先介绍推荐方案并说明推荐理由。对于每种方案，说明：

• 名称；
• 描述；
• 优点；
• 缺点／权衡。

各方案必须有实质性差异，而非仅在表面上有所不同。在适用时，比较复杂度、风险、工作量、灵活性以及与问题的契合度。

请用户确认一种方案。如果用户拒绝所有方案，则修订对需求的理解，并返回必要的步骤。

6. 应用 YAGNI

审查提出的组件和功能，并询问：

• 这是 MVP 必需的吗？
• 它现在能解决核心问题吗？

移除或推迟未通过这些检验的项目。记录移除或推迟了哪些内容，以及原因。如果没有任何项目可以负责任地移除，则记录已完成 YAGNI 审查，且未发现其他可删减内容；不要为了填满此部分而凭空编造删减项。

7. 增量验证

选定方向后，分成简短且可验证的部分介绍方案；内容适合时，每部分以 200–300 个词为宜。

至少进行 2 次检查点，例如：

• 检查点 1：概念、范围和组件；
• 检查点 2：数据流、故障、依赖项和预期行为。

在每个检查点：

1. 介绍该部分；
2. 征求反馈／确认理解；
3. 根据需要进行调整；
4. 然后再继续。

如果用户纠正了之前的理解，应返回并更新受影响的决策。

8. 生成 BRAINSTORM

仅当满足以下条件时，生成该文档：

• 已回答 3 个或更多发现问题；
• 已提出样例问题；
• 已探讨 2 种或更多方案；
• 已应用 YAGNI；
• 已确认一种方案；
• 已完成 2 个或更多检查点。

必须使用 assets/BRAINSTORM_TEMPLATE.md 作为最终文档的权威来源。

生成文件时：

1. 复制／使用该资源作为模板；
2. 用对话中有依据的数据替换所有 {...} 占位符；
3. 仅移除明确标为可选且不适用的部分，例如 Approach C；
4. 保留规范章节的顺序和标题；
5. 资源可用时，不要另行创建不同结构的 Brainstorm；
6. 在模板的适当位置，将未解决的空缺记录为 TBD、N/A、限制或已知依赖项。

最终文件的首选名称为 BRAINSTORM_{FEATURE_NAME}.md，其中 {FEATURE_NAME} 应采用便于阅读且在项目中稳定的格式。

保存位置。 将文件保存到项目根目录下的 sdd/——此目录对任何 Agent 都可见且位置一致。如果项目已有 .claude/sdd/，则继续使用该目录。五个阶段的文档应并排存放，不建立子目录。

如果可以写入项目文件系统，则保存为 sdd/BRAINSTORM_{FEATURE_NAME}.md（若该目录已存在，则保存为 .claude/sdd/BRAINSTORM_{FEATURE_NAME}.md），且不得在不提示的情况下覆盖现有文件。

如果无法访问文件系统，则在聊天中提供完整的 Markdown，并注明建议的文件名。

8.1. 收尾时不要另行开启发现流程

在交接前，将所有已知空缺汇总到 BRAINSTORM 文档中。收尾时不得开启新的工作方向，例如：

• “需要并行获取的主要信息是……”
• “进入下一阶段前，请收集……”
• “Ready for: /define ...”。

下一阶段应将 Brainstorm 作为输入文档。如果探索期间有信息无法获取，应在 Markdown 中将其记录为 TBD、限制或依赖项，不得替换下文定义的 Next Step。

9. 准备交接

Suggested Requirements for /define 部分只能包含对话中有依据的内容：

• 问题陈述草稿；
• 目标用户；
• 可用时提供可衡量的成功标准；
• 约束；
• 范围之外的内容。

不要编造指标。如果成功标准暂时无法量化，应将其标记为待确定，而不是编造数字。

完成后，Next Step 必须仅包含以下指令：

Execute o **SDD Define by RDD**.

不要以 Ready for: /define ... 之类的命令结束。 结尾不要建议并行收集样本、ground truth、代码或其他信息。这些需求应在 Brainstorm 阶段本身处理，并在仍然存在已知缺口时记录在文档中。

验证与质量检查清单

在宣布 brainstorm 完成前，请检查：

• Raw Input 已保留。
• 上下文将事实与推断区分开来。
• 至少回答了 3 个发现问题。
• 问题是一次一个地提出的。
• 已询问样本相关问题。
• 已探索至少 2 种真正不同的方法。
• 有一种附带理由的推荐方法。
• 用户已确认所选方法。
• 已应用 YAGNI，并记录结果。
• 至少完成了 2 个验证检查点。
• 已记录重要决策和被拒绝的替代方案。
• 交接给 Define 的内容仅包含对话中有依据的需求。
• Next Step 仅包含：Execute o **SDD Define by RDD**.
• 结尾不包含 Ready for: /define ...，也不建议并行收集信息。
• 没有将任何不确定性悄然转化为事实。
• 最终文档基于 assets/BRAINSTORM_TEMPLATE.md 生成，且未悄然更改其规范结构。

异常处理

• **用户想跳过问题：**简要说明 brainstorm 仍可继续，但在满足最低门槛前不能完成交接。
• **用户已提供完整需求：**建议直接进入定义阶段，而不是人为延长 brainstorm。
• **回答相互矛盾：**一次提出一个澄清问题，并更新受影响的决策。
• **没有样本：**记录 None available/N/A 并继续。
• **无法访问项目：**不要声称已检查项目结构、提交记录或规范。
• **用户在选择某种方法后改变方向：**重新进行方案比较和 YAGNI 审查，并重复受影响的检查点。
• **没有合适的 YAGNI 削减项：**记录审查结果为未削减；不要编造排除项。

示例

模糊输入 Quero automatizar o processamento de notas fiscais, mas ainda não sei como.

从了解问题和期望结果开始。不要在第一条回复中提出架构。

功能请求 Quero adicionar um chatbot ao portal do cliente.

先询问需求、目标用户和预期结果；然后比较替代方案，包括比完整 chatbot 更简单的解决方案。

附有上下文的笔记 Tenho estas notas de reunião e alguns exemplos de entrada/saída. Faça o brainstorm.

阅读可用材料，保留事实，逐一提出尚未回答的问题，并在提出方案前以样本作为依据。

---

SDD Open by RDD 的一部分 — https://github.com/robertodiasduarte/sdd-open