brainstorm（头脑风暴）
将模糊的问题转化为结构化的候选ADR（架构决策记录）和计划项。 此技能为生成式且只读/只提议——它从不直接写入ADR或计划文件。在获得批准后，它会将每个候选项目移交给new-adr和new-plan技能。
步骤 0 —— 前置条件和上下文
- 确认仓库已引导启动（或说明输出结果可为后续运行的bootstrap技能提供种子数据）。
- 阅读
CONVENTIONS.md以了解ADR的形状和生命周期，快速浏览INDEX.md和现有的ADR，确保候选项目不与现有内容重复或冲突，且依赖关系指向真实的ADR。
步骤 0.5 —— 评估（首先运行）
在分解之前运行共享的评估协议：
-
首先复用已提供的答案。 将请求或本次会话中已提供的适用选择（包括深度）视为已回答。在不再次询问的情况下对其进行总结；默认值绝不能取代明确的选择。如果每个实质性选择都已提供，则直接继续。仅针对缺失或冲突的实质性选择进行提问。仅仓库的首选项不是当前的答案或执行授权。
-
针对未解决的选择使用深度选择器。 如果未提供深度且仍有选择未解决，请询问此评估应深入到什么程度： 快速（Express） —— 每个选择都采用其推荐的默认值；仅询问那些没有可推演默认值的项目（自由文本的必填项）；引导式（Guided） —— 仅询问下面标记为高影响的问题，加上自由文本的必填项；完整（Full） —— 询问下面的所有问题。如果仓库的
CONVENTIONS.md记录了Assessment depth:，则在询问时将其预选为推荐选项；记录的深度绝不会被静默应用。否则，当请求附带的上下文很少时推荐完整（Full），当请求已完全明确时推荐快速（Express）。在任何一个问题处，操作员都可以回答“从这里开始使用默认值”或“更深入”；立即响应此切换。 -
一次只问一个问题，每个问题附带一个推荐选项和一行理由；等待每个回答。
-
使用结构化选择（单选或多选）。如果宿主提供了一个结构化的单选/多选问题工具，请使用它并标记推荐选项；否则以纯文本形式列出A/B/C选项并指明推荐项。仅当无法列举集合时才使用自由文本（例如目标陈述）。
-
由操作员决定。 在没有回答的情况下，永远不要越过问题，并且在无上下文调用时永远不要猜测范围。
问题（跳过请求中已回答的）：
- 目标 / 问题 —— 自由文本（不可避免的开放式回答；在任何深度下都会询问）如果尚未给出。
- 输出 —— 仅候选ADR，或ADR+计划项。 推荐：ADR + 计划项。
- 分解深度 —— 快速（顶级候选）或彻底（完整分解）。 推荐：先快速，根据需要扩展。
这里没有标记为高影响的问题——引导式运行对此技能表现为快速模式。
此技能在您批准大纲之前不写入任何内容。
步骤 1 —— 理解问题
如果未给出目标/功能/问题，请询问。探明范围边界、约束条件以及对此仓库至关重要的监管/质量关注点。在目标明确前不要开始分解。
步骤 2 —— 分解
生成候选列表。对于每个候选ADR：
- 提议的编号（下一个可用的、连续的）、工作标题、形状（如果仓库区分能力与技术决策）。
- 一行范围——它捕获的单个决策。
- 对其他候选ADR或现有ADR的依赖关系。
每个ADR只做一个决策。 如果一个候选ADR捆绑了多个决策，则将其拆分并说明原因。如果一个候选ADR实际上是需要修改的现有ADR，则说明该情况，而不是提议一个新的编号。
步骤 3 —— 安排工作顺序
提出一个计划排序（哪些plan/todo/项目，按什么顺序），并遵循依赖边。标注哪些工作可以并行化（这对agent-wave技能很有用）。
步骤 4 —— 审查与移交
将完整集合呈现为一个可审查的大纲（候选项目 + 依赖关系 + 排序）。接受编辑。仍然不写入任何内容。 一旦用户批准，通过为每个候选项目调用new-adr技能，并为每个已排队的项目调用new-plan技能来创建它们——或者将已批准的大纲移交给这些技能。
防护栏：如果问题过于模糊，无法在不臆断需求的情况下进行分解，请说明情况并要求提供更多信息，而不是生成推测性的ADR。
命名已商定的选项和剩余的决策；仅讨论不会写入任何产物。
结束报告
每次运行结束时，包括被阻止、失败和停止的运行，都必须以一个标题精确为Status at a glance（状态概览） 的章节结束，包含以下三个标签：
- This run（本次运行）： 仅列出实际尝试的操作及其结果；引用每个验证门的确切输出和退出代码，包括超时或中断。
- Overall（总体）： 已实施、部分已验证、已验证、被阻止、失败或未知。通过的子步骤不表示总体通过；不完整或缺失的证据绝不能成为成功。
- Yet to do（待办事项）： 每个剩余的操作、未解决的发现、验证、清理或所需的输入。只有当整个任务可验证地完成时才写入“无”；绝不要因预算结束而遗漏工作。
常规的进度消息不需要此区块。保持最终结果简洁，并区分在PR上准备的工作和确认已交付的工作。