brainstorm

头脑风暴

通过对话将原始想法整理成一致的方案，为编写规格做好准备——而不是写代码。

所处阶段： brainstorm → (write-requirements → write-design → write-plan) → execute-plan。你现在处于 brainstorm 阶段——第一阶段。后续运行哪些阶段，由步骤 5 中的层级决定（层级 0 直接跳到 tdd；层级 1 在 write-requirements 中止，产出迷你规格；只有层级 2 会完整走完三个阶段）。每个阶段都有自己的待办列表，并会在调用时创建列表——不要提前将它们的步骤加载到本技能的列表中。

要梳理一个新功能或项目（尚未编写规格），请使用本技能。对已发布且已有规格的功能进行小幅范围内修改，则应使用 amend——它会读取现有规格，并将修改引导至轻量流程；只有当修改确实涉及新范围时，才会升级回此流程。如果交给你的是这类修改，请将其交给 amend。

在此清单全部完成，并且你已明确说出流程层级之前，绝不编写代码、搭建任何脚手架或调用任何实施技能。对于层级 0，唯一允许的后续步骤是 `tdd`，且只能在说出层级之后进行；对于层级 ≥1，必须先编写并获批需求。本技能允许操作的产物仅限于笔记、词汇表（CONTEXT.md）、ADR、路线图（`docs/roadmap/INDEX.md`，且只能在步骤 5 通过 `write-roadmap` 操作），以及通过其子技能生成的研究笔记和明确标记为一次性用途的原型。此规定适用于**每一项**请求，无论请求看起来多么简单。

“太简单了，不需要设计”是个陷阱

小需求恰恰最容易因未经验证的假设而浪费大量工作，因为没人费心检查。最终产出可以很精简——一个层级决策和三句话——但每次都必须走完流程。

想法	实际情况
“这只需写一行，设计只是额外负担”	判断它属于层级 0 就是设计步骤——明确说出来，然后继续。跳过判断才是额外负担。
“用户已经明确告诉我该怎么做了”	用户告诉你的是解决方案。你还没有确认问题、约束条件，或哪些现有功能必须继续正常运行。
“我先写点代码理清思路”	那是原型。运行 prototype 子技能，按约定确保它是一次性的，而不是意外变成生产代码。
“我确认方案能编译后再写需求”	先写代码颠倒了流程门槛。有关证据的问题应通过研究或原型绕行解决；需求仍须先写。
“搭脚手架不算真正的实施”	仓库骨架是在未经批准的情况下落实技术栈决策。这就是实施。
“我们聊得够多了，我基本知道答案”	如果内容没有写入获批的 requirements.md，就只存在于当前对话中，对话结束便会消失。
“其他子功能目前不在范围内，所以应该放到 Out-of-Scope”	Out-of-Scope 和 ADR 记录的是拒绝事项。计划稍后开展的工作应通过 write-roadmap 延后到某个里程碑——拒绝它会毁掉你刚刚制定的计划。

危险信号——如果发现自己有以下行为，请停下并返回清单： 打开编辑器说“只是试试看”；运行生成器或脚手架工具；不提问就自行回答尚未解决的问题；把一种方案说成唯一选项；从访谈逐渐转向实施。

检查清单

先创建待办 — 闸门。 每次头脑风暴的第一步——在阅读 CONTEXT.md、派遣扫描任务或提出任何问题之前——都是创建待办清单：使用你的运行环境提供的待办工具（Claude Code 中的 TodoWrite；在 Kimi、Codex 或其他运行环境中使用相应工具），为下面检查清单中的每个步骤（步骤 1–6）各创建一条待办。每个请求都必须执行，无论看起来多简单——上面的硬性闸门规定了绝对不能做什么；这一步规定了必须先做什么。清单中只能包含此技能的六个步骤；不要添加后续阶段（write-requirements、write-design、write-plan）——交接时，每个阶段都会创建自己的清单。清单创建完成后才能继续，然后按顺序完成各项，只有达到各项的完成条件时才能勾选。

尽早判断层级，合理安排工作量。 步骤 1 提供上下文后，先做出一个暂定层级判断：

• 显然属于第 0 层 — 拼写错误、重新着色、标签或文案编辑，没有行为变更、未经确认的假设，也没有需要防范的风险 → 简要执行步骤 2，跳过步骤 3–4，然后执行步骤 5。
• 其他所有情况 — 行为变更、未知事项或实际设计选择 → 执行完整流程。

暂定判断只是暂定：如果步骤 2 发现上述任何一种情况，那就说明它从来都不属于第 0 层——升级到完整流程。

1. 探索项目上下文

直接阅读 CONTEXT.md（后续统一使用其中的术语）和 docs/specs/INDEX.md（其中列出了已有的功能代码和规格说明）——这些文件很小，需要了解其中的内容。如果存在 docs/agents/project.md，阅读其中的项目定位：交付意图和生命周期阶段会影响整个访谈的工作量——若项目定位为原型／研究／学习，就不要把问题浪费在数据迁移、向后兼容或弃用成本上；若项目定位为已发布／扩展中／维护中，则要重点权衡这些因素。如果没有项目定位部分，不要擅自假设；直接继续，不作调整。如果同一文件中存在 ## Team，则在团队名册非空或设置了工作流层级覆盖项时，根据该部分的规则和矩阵确定层级并应用打包方式（不要在此重复照抄规则）。只说明一次层级。单人团队：方案中采用更精简的同行协作表述。小型／多成员团队：在方案权衡中明确说明负责人和审查能力。团队名册为空且覆盖项为空，或缺少 Team 部分：不要臆造团队，也不要因此中止。如果存在 docs/product/vision.md，也要阅读；理解构想后，说明它是否符合产品已声明的范围（若构想超出范围，值得在编写规格之前提出）；若该文件不存在，则跳过，此层为可选。对于更复杂的事项——代码、文档以及与此构想相关的近期提交——派遣一个扫描子 Agent，探索并将发现摘要写入 .skills/<slug>-scan.md（说明构想附近已有的内容、涉及的文件和接口，以及适用的约束——提供发现，而非倾倒文件内容），并且只返回该路径；后续基于摘要开展工作，不要把原始文件内容拉进此对话。（如果此运行环境不支持子 Agent，就直接阅读少量相关文件。）如果 docs/agents/project.md 或上述文件缺失，说明这一点，建议运行 setup-repo，并根据已有信息继续。

扫描摘要（或直接阅读所得内容）必须包含 盲点 部分：针对该领域的陷阱、历史约束，以及新手不会想到要问的问题——这些内容必须基于此代码仓库，而非通用建议。如果用户表示自己不太熟悉该模块或领域，请在步骤 2 提出第一个偏好问题之前，先向用户展示盲点清单。 然后检查该想法是否已经存在。搜索 docs/specs/，查看是否有重叠：在 requirements.md 文件中 grep 该想法的候选功能代码和关键术语，并将扫描得到的候选文件路径与现有规格说明已覆盖的路径交叉核对（在 design.md/tasks.md 中 grep 这些路径）。阅读任何匹配项，并以摘要卡片形式呈现相邻规格说明（而非完整规格说明）——其功能代码、覆盖路径和 Out-of-Scope 列表可以显示它已涵盖的内容。首先查阅 docs/specs/INDEX.md 注册表。这绝不会阻止流程：如果没有重叠，就说明这一点并继续；如果 docs/specs/ 尚不存在，就注明这一点并继续手动探索。

已知项清单（进入步骤 2 前必须完成）。 写出四条简短要点，供后续流程复用（可写在聊天中；也可选写入 .skills/<slug>-knowns.md）：

• 已知的已知项／锁定项——已确定的硬性约束和结果（必须保留的行为、立场约束、明确不可妥协的事项）。
• 已知的未知项——需要研究、原型验证或用户决策的开放问题。
• 未知的已知项——用户能识别但尚无法明确描述的偏好或标准（通过 prototype 或参考资料处理，不要只靠更多文字提问）。
• 假设（非锁定项）——用户提出但仍属于假设的解决方案形态，须先与实际情况（代码库、API、历史记录）核对。绝不能在假设被选为锁定项之前，将其提升为需求 SHALL。

**完成条件：**你能用一段话说明项目是什么、这个想法附近已有何种内容，以及适用哪些术语表词条；并且已说明哪些现有功能与该想法涉及相同范围，以及新想法有何不同（引用功能代码），或说明没有现有功能涉及相同范围——并且已创建已知项清单和盲点列表。

2. 访谈

这仍然是头脑风暴的第 2 步——不是阶段交接，也不是新的技能会话。对唯一提问渠道应用 grilling 协议；保持此技能的待办列表持续有效；不要另开一份相互竞争的列表，也不要再次宣布你正在“切换到 grilling”。

**协议（始终适用）：**此步骤全程应用 grilling——包括渠道、开放集停止规则、丰富问题卡片槽位和收尾包。不要根据本段自行设计更简化的访谈；卡片制作方法和停止规则仅在 grilling 中定义。

必需子技能：使用 grilling 获取完整规则（渠道 Iron Law、开放集 Iron Law、丰富问题卡片制作方法、实现前访谈图谱、收尾包、立场精简、团队规模分档打包、no-enact gate、嵌套待办约定）。若该技能尚未在当前上下文中，步骤开始时加载一次；随后继续遵循此清单。

（根据早期阅读暂定为 tier 0？请合理控制范围：用一两个问题确认问题、唯一约束以及必须继续正常工作的部分——不要完整走一遍决策树；如果没有出现新情况，就继续到步骤 5。）

整个访谈期间，让 domain-modeling 作为被动副作用保持启用：术语一旦确定，就立即记录到 CONTEXT.md 并交叉引用代码——但它不会开启第二个提问渠道。若某个术语需要用户参与（挑战、消歧、边界情况探查），它就成为访谈单一提问流中的下一个问题，不得作为相互竞争的打断（必需子技能：使用 domain-modeling）。

深入细节前，先检查范围：如果请求涉及多个相互独立的子系统，就停止细化并先进行拆解（步骤 5）。

**完成条件：**开放集中已没有影响范围大的判断事项，并且已确认 grilling 收尾包。

3. 问题需要证据而非观点时，转而调查

仅适用于完整路径；tier 0 会跳过此步骤。

有些问题无法凭偏好作答。诚实的答案是“我们得查证一下”时：

• 关于外部系统、API、库或标准的事实 → 必需子技能：使用 research（一手资料、附带引用的说明——它会调用 Context7 MCP 获取当前且版本准确的库信息，而非依赖训练数据截止时的信息）。
• “这个模型／流程实际用起来感觉合适吗？” → 必需子技能：使用 prototype（可运行的一次性答案）。

带着证据回到访谈，把决定交还给用户。

完成条件： 没有任何待回答的问题仍在靠猜测作答。

4. 提出方案

仅适用于完整路径；tier 0 会跳过此步骤。

提出 2–3 个真正不同的方案，并说明各自的权衡。先给出你的建议及理由。对每个选项都应用 YAGNI 原则进行精简。由用户选择。

完成条件： 用户已选择方案（也可以是混合方案）。

5. 明确决定流程规范等级

明确说明等级及理由：

等级	适用情况	后续步骤
0	拼写错误级别，不改变行为	不写规范——直接进入 tdd
1	行为变更不超过约半天的工作量	迷你规范：在所属的 requirements.md 中修复 REQ + SHALL-CONTINUE-TO 守卫
2	多任务功能	完整的 requirements → design → plan 三件套

如果工作跨越多个相互独立的子系统，请在此处拆解：列出子功能、它们之间的关系以及构建顺序。每个子功能都要有自己的完整规范流程。

两个或更多子功能意味着必须先记录拆解结果，才能继续。 必需子技能：使用 write-roadmap 将每个子功能作为 ROAD-N 条目记录下来——如果 docs/roadmap/INDEX.md 已存在，则追加到其中；如果不存在，则创建该文件。尚未优先构建的子功能是推迟到后续里程碑，而非拒绝：Out-of-Scope 条目或 ADR 记录的是拒绝，拆解并不代表拒绝。然后只继续处理第一项。

完成条件： 你已说明“这是等级 N，因为……”，并且若进行了拆解，每个子功能都已作为 ROAD-N 写入 docs/roadmap/INDEX.md，且你已指出优先处理哪一项。

6. 终止状态

• 等级 ≥ 1： 必需子技能：使用 write-requirements。这是唯一的退出路径。不要编写代码、不要搭建脚手架、不要直接调用任何实现或设计技能——先编写需求，并通过其自带的审批关卡。
• 等级 0： 说明等级，然后必需子技能：使用 tdd。

完成条件： 已调用 write-requirements（等级 ≥ 1），或已说明等级为 0 并移交至下一步。