brainstorm

/brainstorm —— 在规划前明确目标

目的： 区分“做什么”和“怎么做”。在决定解决方案前，先探索问题空间。

循环中的位置

位于运行循环中的步骤 **1（以 BDD 形式确定意图）**之前。接收自由文本目标；生成采用 Given/When/Then 格式的验收示例，供 /discovery 纳入 BDD 意图 issue。除非至少将一个顺利路径和一个关键边界情况写成可测试的 Gherkin，否则第 4 阶段的 Capture 步骤尚未完成——“应该能正常工作”不算已捕获的示例。

两种模式

/brainstorm 以两种模式之一运行。两者互为补充，并非互斥——一次会话可以从创意构思模式开始，选定一个想法后，再交由目标明确模式探索 HOW。

模式	使用时机	形式
目标明确（默认；以下四个阶段）	目标指明一项具体能力（"add JWT auth"、"fix the login bug"）	明确单一目标的 WHAT，并探索其 HOW。
创意构思（开放式；参见创意构思模式）	目标开放式（"improve the project"、"what should we build next"），或第 1 阶段返回 exploring，但未能明确单一目标，或传入 --ideate	生成许多候选改进，严格筛选，并将入选方案转化为可执行内容。

完整的模式选择表见 references/ideation-mode.md。

四个阶段（目标明确模式）：

1. 评估清晰度 — 目标是否足够具体？
2. 理解想法 — 问题是什么、谁会受益、现有情况如何？
3. 探索方案 — 生成选项、比较取舍，并进行对抗式评议
4. 记录设计 — 编写供 /plan 使用的结构化输出

---

快速开始

/brainstorm "add user authentication"     # full 4-phase process
/brainstorm                                # prompts for goal

---

执行步骤

阶段 1：评估清晰度

如果用户提供了目标字符串，就对其进行评估；否则，请用户提供一个目标。

使用 AskUserQuestion 提供选项，以评估清晰度：

• clear — 目标具体且可执行（例如，“为 API 添加 JWT 身份验证”）
• vague — 有目标，但需要进一步明确范围（例如，“提升安全性”）
• exploring — 还没有明确目标，只有一个方向（例如，“身份验证相关的东西”）

如果选择 vague 或 exploring，请提出后续问题，在继续之前明确目标。只有在获得具体的问题陈述（一句话，可测试）后，才能进入阶段 2。

阶段 2：理解想法

回答以下问题（根据需要探索代码库）：

1. 这要解决什么问题？ — 具体说明痛点。
2. 谁会受益？ — 终端用户、开发者、运维人员，还是 CI 流水线？
3. 目前有什么？ — 当前状态、代码库中的既有方案、相邻系统。
4. 哪些约束很重要？ — 性能、兼容性、安全性、时间安排。

进入下一步前，先总结发现。如果有任何内容不清楚，请询问用户。

阶段 3：探索方案

生成 2-3 个不同的方案。每个方案都应包括：

• 名称 — 简短标签（例如，“JWT 中间件”“OAuth 代理”“会话 Cookie”）
• 工作原理 — 用 2-3 句话说明
• 优点 — 方案的正确之处
• 缺点 — 方案的不足之处或暂缓处理的内容
• 工作量 — 大致范围（小 / 中 / 大）

阶段 3b：对抗性评审

请用户选择之前，先对每种方案进行压力测试：

针对每种方案，回答以下红队问题（请阅读 references/red-team-checklist.md）：

1. 什么会最先出问题？ — 在高负载、边缘情况或恶意输入下
2. 隐藏成本是什么？ — 维护负担、技术债、学习曲线
3. 哪个假设是错的？ — 让这种方案看起来不错的未明说的信念
4. 谁会持反对意见？ — 偏好相反的资深工程师会怎么说？

如果某种方案未通过 2 个或更多红队问题的检验，请在对比中将其标记为高风险。

如果所有方案都未通过 2 个或更多问题的检验，请生成第 4 种“混合”方案来解决这些弱点。

展示对比结果，并使用 AskUserQuestion 让用户选择一种方案或请求混合方案。

阶段 4：记录设计

生成日期标识：YYYY-MM-DD-<goal-slug>（小写，使用连字符，不含空格）。

将输出文件写入 .agents/brainstorm/YYYY-MM-DD-<slug>.md：

---
id: brainstorm-YYYY-MM-DD-<goal-slug>
type: brainstorm
date: YYYY-MM-DD
---
# Brainstorm: <Goal>
## Problem Statement
## Approaches Considered
## Selected Approach
## Open Questions
## Next Step: /plan

必须填写全部五个部分。“下一步”部分应包含具体的 /plan 调用建议，并以选定方案为上下文。

如果 .agents/brainstorm/ 目录不存在，请创建该目录。

---

构思模式（开放式生成与筛选）

在上述四阶段流程基础上追加，不会取代它。 构思模式适用于“改进项目”这类目标，即 WHAT 尚不明确，你必须生成一个方案组合并进行筛选，而不是澄清一个已知目标。完整详情：references/ideation-mode.md。

触发条件： 阶段 1 中的 exploring 清晰度路径在跟进后仍未出现单一目标；或显式指定 --ideate 标志；或目标字符串较为开放（"improve the project"、"what should we build next"、"make X more robust"）。

方法为生成 → 筛选 → 扩展 → 操作化 → 优化。步骤 1-3 属于 /brainstorm；步骤 4-5 移交给 /discovery 的开放式路径（见 references/bead-operationalization.md）。

步骤 1 — 立足现实

读取项目状态，让想法与现状相符且避免重复工作：

cat AGENTS.md                      # or CLAUDE.md — rules, constraints, non-goals
bd list --json                     # open work — don't duplicate
bd list --status closed --json     # closed work — don't re-propose cut ideas
bd ready --json                    # what is actionable now

步骤 2 — 生成 30 个，筛选至 5 个（排序并说明理由）

生成 30 个候选改进项（评估维度 = 评分标准维度：稳健、可靠、高性能、直观、易用、符合人体工学、有用、有吸引力，同时显然是增量式且务实的）。认真思考每个想法：如何运作、用户如何看待它、如何实现。然后严格筛选出最好的 5 个，按从最好到最差排序展示，并提供完整理由和评分标准得分。按照 references/idea-rubric.md 中的筛选轮次和评分方法进行筛选，并使用 references/red-team-checklist.md 对入围想法进行压力测试。不要只列出最先想到的 5 个——先生成完整的 30 个。

步骤 3 — 用接下来的 10 个扩展（→ 15）

生成接下来最好的 10 个（每个都附上理由），组成包含 15 个想法的排序组合——第 #6-15 项通常能与前 5 项互为补充。

步骤 4-5 — 操作化 + 优化（移交给 /discovery）

将这 15 个按排名排列的想法（附带如何运作/用户感受/实现方式说明 + 评分标准得分 + 红队调查结果）继续传递下去。/discovery 会将它们操作化为自我说明的 bd 工单（包含依赖项 + 明确的测试任务），并在计划阶段进行 4-5 轮优化。见 references/bead-operationalization.md。

输出

独立运行（/brainstorm --ideate）：将排序后的方案组合写入 .agents/brainstorm/YYYY-MM-DD-<slug>-ideation.md（模板见 references/ideation-mode.md）。由 /discovery 调用：在操作化步骤中以内联方式返回排序后的方案组合。

跟踪使用 bd，绝不使用 br/bv — 这是 AgentOps。

---

终止条件

阶段 4 的输出已写入 = 完成。没有后续阶段，也不循环。

验证

写入输出文件后，请验证：

1. 文件存在于预期路径
2. 所有 5 个章节（Problem Statement、Approaches Considered、Selected Approach、Open Questions、Next Step: /plan）均已包含且非空

向用户报告文件路径。

---

示例

示例 1：具体目标

User: /brainstorm "add rate limiting to the API"

Phase 1: Goal is clear — add rate limiting to the API.
Phase 2: Problem is uncontrolled request volume causing timeouts.
         Benefits operators and end users. No rate limiting exists today.
Phase 3: Three approaches — token bucket middleware, API gateway,
         per-route decorators. User picks token bucket.
Phase 4: Writes .agents/brainstorm/2026-02-17-rate-limiting.md

示例 2：模糊目标

User: /brainstorm "improve performance"

Phase 1: Goal is vague. Asks: "Which part? API response times,
         build speed, database queries, or something else?"
         User says: "API response times on the search endpoint."
Phase 2: Investigates search endpoint, finds N+1 queries.
Phase 3: Approaches — query optimization, caching layer, pagination.
Phase 4: Writes .agents/brainstorm/2026-02-17-search-performance.md

---

故障排除

问题	原因	解决方案
第 1 阶段的头脑风暴陷入循环，无法推进	经过后续提问后，目标仍然过于模糊	提供具体、可测试的问题陈述（例如，“将 API 搜索延迟降低到 200ms 以下”，而不是“提升性能”）。
输出文件缺少一个或多个必需章节	第 4 阶段被中断，或技能提前终止	使用相同目标重新运行 /brainstorm；确认输出中包含所有 5 个章节（Problem Statement、Approaches Considered、Selected Approach、Open Questions、Next Step: /plan）。
未创建 .agents/brainstorm/ 目录	技能无法创建目录（权限或路径问题）	使用 mkdir -p .agents/brainstorm 手动创建，然后重新运行。
“Next Step”章节中的 /plan 调用过于笼统或不完整	所选方法不够具体，无法生成明确的计划命令	编辑输出文件以完善所选方法，然后编写包含方法名称和关键约束的 /plan 调用。
第 3 阶段的头脑风暴只产生了一种方法	问题空间范围狭窄，或目标限制过多	稍微扩大目标范围，或明确要求提供替代方法（例如，“考虑缓存方法和查询优化方法”）。

---

另请参阅

• skills/plan/SKILL.md — 将所选方法拆解为可执行的问题

参考文档

• references/brainstorm.feature — 可执行规范：4 阶段澄清（关注做什么，而非怎么做）、选项与权衡，以及为 /plan 记录 Gherkin（正常流程 + 边缘情况）（soc-qk4b）

• references/red-team-checklist.md — 第 3b 阶段的对抗式评审模板

• references/ideation-mode.md — 开放式生成与筛选方法：模式选择表、生成 30 个 → 筛选至 5 个 → 扩展至 15 个、输出模板（ag-yw0）

• references/idea-rubric.md — 十维评估标准（稳健/可靠/高性能/直观/用户友好/符合人体工学/有用/有吸引力/累积增益/务实）+ 多轮筛选（ag-yw0）

• references/bead-operationalization.md — 将排名后的组合转化为自说明的 bd beads（依赖项 + 测试任务），并在计划阶段进行 4–5 轮完善（ag-yw0）