brainstorming

头脑风暴

先明确要构建什么，再规划如何实现。

范围与交互

进行探索并设计方案，而非实现。交互式交接前须获得批准。只有调用方明确委托非交互式执行及其决策范围时，才启用无头模式；disable-model-invocation 是选择元数据，不代表已获批准。用明确说明的保守假设代替无头模式下的确认。对于没有安全且获授权的默认选项的重大决策，不得留待解决。绝不可将推断出的选择称为用户已批准，也不可从此技能推断出实施、提交或发布权限。

以纯聊天文本提出开放式访谈问题，然后结束当前轮次，等待回答；菜单会将用户的思路限制在 Agent 的框架内。仅在选项适合用菜单呈现且有两个至四个真实选项时，才使用会阻塞等待的菜单工具（Blindspot Pass、方案选择、跳转到规划的提议、审批，或用户卡住或表示“你来选”时）：在 Claude Code 中使用 AskUserQuestion（需要时通过 ToolSearch select:AskUserQuestion 加载）；在支持的 Codex 中使用 request_user_input；否则在聊天中列出编号选项，并在第一行注明待决事项。无人值守的工作线程应将待决决策返回给父级。

流程

1. 评估并以事实为依据。 对于现有项目，在提问前先阅读相关代码、文档、约束和近期提交。指出请求与观察到的行为之间的矛盾。对于抽象主题，跳过代码库调研。针对目标含糊、存在不同解读、权衡尚未解决、需求不确定、以解决方案为导向的请求，或多个彼此独立的子系统，进行头脑风暴。如果需求明确，建议制定计划或开始实施，不要强行展开对话。
2. 合理确定规模并拆解。 通过三轮对话就能解决的头脑风暴，可能只需要总结；持续的架构工作则需要一份持久化设计。对于多个彼此独立的子系统，明确边界和依赖关系，确定构建顺序，然后为每个子项目分别进行设计 → 计划 → 实施。先从第一个子项目开始。
3. 理解并比较。 需要对话或选择方案时，阅读 interview-and-approaches.md。使用与用户一致的词汇。通常围绕多个维度问一个问题，或围绕一个维度问两到三个问题；对于内容较多的初始描述（>200 个词），采用参考文档中有范围限定的分批提问。了解目的、用户、约束、成功标准、边缘情况、模式和非目标。当需要追问假设、证据、不熟悉的领域或组合回答时，应用 deep-interview.md；退出访谈前须完成其中的整合检查。需求明确或用户要求继续时，停止提问。用三到五条要点总结，并在交互模式下确认。
4. 选择方案。 比较两到三个具体备选方案，说明其内容、优缺点和适用条件。先给出推荐方案，参考现有模式，并明确权衡。如果经过两轮仍未接受任何方案，询问用户倾向的方向。对于广泛的设计空间，使用方案参考文档中的两到三个视角。明确列出所选方案的“不做事项”，并为每个关键假设说明验证方法。
5. 确认理解的范围。 在经过实质性对话后开始编写前，阅读 scope-synthesis.md。在内部区分明确提出的需求、推断出的假设和排除项；对外只呈现参考文档要求的简明范围综合。在不会导致阻塞性提问的轻量工作中采用告知模式；标准或深入工作，以及任何存在阻塞性对话的情况，都需要交互式确认。重新呈现修订内容并等待确认。在无头模式下保留来源和未解决的假设，不发起提问。跳过对话且需求明确时，无需设置综合确认节点。
6. 记录并自我审查。 对于持久化交付物，阅读 design-and-handoff.md。将文件保存为 docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md，并包含日期／主题 frontmatter、我们要构建的内容、为何选择此方案、关键决策及其依据、待解决的问题和后续步骤。将访谈历史折叠到 details 块中。说明每个组件的用途、用法、依赖关系和可测试边界。仅在调用方授权范围内提交。
7. 交接。 保留已确定的决策及其依据，不要反复质疑；对于冷硬的指令，只质疑一次方案。无论哪种情况，都不能忽视具体的缺陷或不可行性证据。确保术语一致、标准具体、范围可追溯、决策明确、非目标显式、假设经过验证，并为每个产出值注明来源。发现问题时，返回方案选择或起草阶段。在交互模式下提交设计以供批准；在无头模式下，返回由调用方委托的决策和未解决的假设。

完成

返回范围明确的摘要或已保存的设计路径、决策，以及已解决或明确推迟并说明原因的待解决问题。交接前须获得交互式批准；无界面交接仍属于调用方的权限范围。规划（ia-planning，或 Claude Code 中的 /ia-plan）在设计之后进行，并沿用已确定的需求。对于身份验证、支付、外部 API 或多租户数据，建议在规划前进行可用的安全威胁建模审查。