ce-brainstorm

脑暴功能或改进事项

注意：当前年份为 2026 年。 在为纯需求统一方案标注日期时请使用此年份。

头脑风暴通过协同对话帮助回答**构建什么（WHAT）的问题。它处于 ce-plan 前置环节，后者会在同一个统一方案产物中补充如何构建（HOW）**的具体内容。

该工作流的持久化产出是一份纯需求统一方案（requirements-only unified plan）。在其他工作流中，这可能被称为轻量级 PRD 或功能简报（feature brief）。在复合工程（compound engineering）中，请保持工作流名称为 brainstorm，但将首版方案产物写入 <root>/plans/ 目录下，并标记 artifact_readiness: requirements-only，以便后续规划阶段无需自行凭空捏造产品行为、范围边界或成功标准。

本 Skill 不负责编写或实现代码，只负责探索、明确并记录决策，供后续规划或执行阶段使用。

核心原则

1. 先评估范围 - 规范流程与文档仪式感的轻重，要与任务的大小和模糊程度相匹配。
2. 充当思考伙伴 - 给出替代方案、质疑既有假设并探索各种假设情况，而不是单纯提取需求。
3. 在此处拍板产品决策 - 面向用户的行为、范围边界和成功标准属于本工作流的职责；具体实现细节留给规划阶段。
4. 默认不将实现细节纳入产品契约 - 除非脑暴主题本身就是技术或架构变更，否则不要写入具体代码库、Schema、API 接口、文件布局或代码级设计。
5. 产物体量要得当 - 简单任务只需一份简明的纯需求统一方案或短期对齐文档；大型任务则应补充更完整的产品契约（Product Contract）。切勿增加对规划毫无助益的冗余仪式。
6. 将 YAGNI 原则应用于长期维护成本，而非单次编码工作量 - 优先选择能交付核心价值的最简方案。避免推测性复杂度和虚无缥缈的“面向未来设计”，但如果某种低成本的打磨或惊喜体验后续维护开销极小，则值得纳入。
7. 勿将覆盖需求误作任务拆解 - 在软件脑暴中，对于明确指名的设备、服务商和数据源，应视为兼容覆盖要求，而非自动拆分为独立的集成工作流。只有当通用接入路径无法满足特定需求时才拆分。连接器（connector）的具体选型交由规划阶段决定，除非该选择会实质性改变产品范围或行为。
8. 每份产物保持独立且连贯的工作单元 - 当需求包含可独立规划和交付且各自有价值的成果时，在深入探索前先锁定其中一个作为当前重点。保留对周边关联工作的既有理解，但不要将未来暂定的规划强行变成本方案的硬性需求。

交互规则

这些规则适用于所有头脑风暴场景，包括路由至 references/universal-brainstorming.md 的通用（非软件）流程。

1. 一次只问一个问题 - 每轮对话仅抛出一个问题，即使子问题看起来高度相关也不要堆叠。在一条消息里堆砌多个问题会导致回答质量打折扣；挑出最核心的一个提问即可。
2. 优先使用单选多项题 - 当需要确定单一方向、优先级或下一步行动时，提供单选题。
3. 谨慎且有针对性地使用多选题 - 仅在选择可共存的集合（如目标、约束条件、非目标或成功标准）时使用多选。如果涉及优先级，后续需跟进询问哪个选项是首要的。
4. 默认使用宿主平台的阻塞式提问工具 - 在 Claude Code 中使用 AskUserQuestion（若未加载 Schema 先调用 ToolSearch 加载 select:AskUserQuestion），在 Codex 中使用 request_user_input，在 Antigravity CLI（agy）中使用 ask_question，在 Pi 中使用 ask_user（需安装 pi-ask-user 扩展）。这些工具均自带自由文本兜底，精心设计的选项既能引导回答又不会限制思考。不论是破题开场、需求启发还是收拢范围，均应默认使用该方式。只有当宿主环境中确实不存在阻塞式工具（包括 ToolSearch 未匹配到）或调用报错（如 Codex 编辑模式）时，才退回使用聊天框中的数字编号选项——绝不能仅因需要加载 Schema 就放弃使用。切勿静默跳过提问。**例外情况——视觉探针卡口（visual-probe gate）：**对于本质上偏视觉的主题（Phase 0.3 触发条件），首个关于形态/行为/状态/布局/流程/架构图的决策须遵循 references/visual-probes.md，其优先级高于本规则。详见 Phase 1.3 卡口。
5. 仅在问题确实开放时使用开放式提问 - 当回答天然偏向叙述性、预设选项会误导诊断/自省性回答、或者无法凑出 3-4 个真正独立且合理的选项时，停用阻塞式工具。判断标准：如果你需要硬凑选项，就说明这是个开放式问题——直接开放提问即可。规则 1 依然适用：一轮只问一个问题。
6. 开放式提问必须足够具体才能引出实质内容 - 静默执行规则 5：直接提问，无需解释为何选择此提问形式。问题必须提供具体的锚点供用户思考。好的示例：“针对这个问题，目前最具体的实际行动是什么——比如已经掏钱购买、折腾出临时替代方案，还是干脆弃用了某个工具？”——明确指出了怎样的回答才算数。过于单薄的示例：“你怎么看？”——毫无抓手；同理，暗示简短回答（如“简要说说”、“是否同意”）也是对开放式提问的浪费。

产物根目录

本 Skill 会将纯需求方案写入 <root>/plans/ 目录。请在首次拼接 <root>/ 路径时（按下方逻辑）解析 <root>，不要提前解析。无论是向 <root>/... 写入还是读取 <root>/solutions/，均算作拼接 <root>/ 路径，都会触发解析；只有完全不触及 <root>/ 路径的运行（如纯草稿或无 repo 流程）才可跳过。

<!-- ce-docs-root:start -->
在拼接任何产物路径前，先解析 CE 产物根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.local.yaml 中的 docs_root，若无则读取 config.yaml；以首个非空值为准（<repo-root> = git rev-parse --show-toplevel）。若均未设置 -> <root> 默认为 docs，与此前一致。
• 校验 设置的值：必须是相对于 repo 的目录，且解析软链接后的真实路径必须位于 repo 内部，既不能是 repo 根目录，也不能在 .git/ 之下。否则停止运行并报出包含 docs_root 及该值的错误信息——绝不静默退回 docs。
• 使用 <root> 作为唯一的产物存放位置：若不存在则创建，按 <root>/<subdir> 拼接本 Skill 专属子目录路径，且不再读取 docs。
  <!-- ce-docs-root:end -->

输出指导

• 优先保留影响决策的细节 - 务必保留下一步决策所需的事实、权衡考量（tradeoffs）和注意事项；优先剪裁介绍性文字、重复内容及可有可无的背景说明。

模型分级 (Model Tiers)

子 Agent 的调度按任务类型分级，绝不硬编码模型名称。在调度 Phase 1.1 事实调研员（grounding scout）、Phase 2.6 主张校验员（claim verifier）或选配的 Slack 调研员时，请阅读 references/model-tiers.md 获取各分级定义（提取 / 生成 / 顶配）以及在不支持单 Agent 模型选择或完全无子 Agent 原生的平台上的降级规则。

功能描述 (Feature Description)

功能描述是触发本 Skill 时传入的输入——即需要探索的内容，包含在当前 Prompt 或对话中，无论是由用户直接提供还是上游 Skill 传递而来。

若未提供功能描述，询问用户：“你想探索什么想法？请描述你正在构思的功能、问题或改进事项。”

在获取用户的功能描述之前，不要继续向下执行。

会话已定决策（Session-settled decisions）。 调用的对话上下文，或作为输入传入的提炼简报（来自用户或上游 Skill），可能包含已经过探讨并敲定的决策。在对对话所含决策进行分类前，请阅读 references/settled-decisions.md——其中定义了敲定判定测试、两类来源分类、标注格式以及捕获规则。跳过分类会导致双向失误：要么重复询问用户已做出的决策，要么误将未经考察的断言提升为已敲定决策。

执行流程

Phase 0: 恢复、评估与路由

0.0 确定输出模式

在触发任何其他阶段之前确定 OUTPUT_FORMAT。输出模式具有排他性——纯需求统一方案要么写为 Markdown (.md)，要么写为 HTML (.html)，绝不同时生成两种。优先级顺序：Prompt 内明确指定 > 用户既定偏好 > 配置文件设置 > 默认值 (md)，且管道模式具有硬性覆盖权限。

读取配置。 运行时通过 Shell 工具执行 git rev-parse --show-toplevel 解析 <repo-root>。然后使用原生文件读取工具读取 <repo-root>/.compound-engineering/config.local.yaml。若无法解析根目录（非 git 仓库）或文件不存在，则顺延使用下文的默认设置。

解析步骤：

1. Prompt 内明确指定。 分析用户在本轮运行中的 Prompt，检查是否对本文档的输出格式提出了要求（表现为 output: 简写或自然语言描述，如“生成网页形式”、“我要 HTML 格式”）。对于明确的格式请求，不区分大小写匹配 md/html；同时在将 Prompt 剩余部分作为功能描述读取时，忽略 output: 简写标记。注意区分“对文档格式的要求”与“作为讨论主题的格式”：如“探索 HTML 导出功能”属于任务内容本身而非文档格式要求，不要因此切换格式。
   • 单独出现 output:（未附带值）→ 无效操作，顺延至步骤 2。
   • output:<未知格式>（例如 output:pdf）→ 丢弃该标记，顺延至步骤 2，并注意在最终解析完成后、于生成后菜单上方输出一行提示：Ignored unknown output: value '<value>' — using <resolved_format> instead.，其中 <resolved_format> 为完成剩余优先级步骤后实际解析出的 OUTPUT_FORMAT 值。切勿在提示中硬编码 md——因为当配置项设为 HTML 时硬编码 md 会误导用户。
2. 用户既定偏好。 若当前 Prompt 未指定格式，则遵循用户此前建立的输出格式偏好（Markdown vs HTML）——该偏好可能来自本会话早前对话、你的记忆或写入其有效指令中，且已存在于你的上下文（不区分大小写匹配 md/html）。记忆中的偏好比极少修改的配置更新，因此它会覆盖步骤 3 中的配置。不要特意打开或搜索指令文件去查找——仅根据已存在于上下文中的偏好执行；若无，则顺延至配置项。
3. 配置文件。 若步骤 1-2 未能解析出结果，且上文读取的配置文件中包含**生效中（未被注释）**的 brainstorm_output: 键，且其值为 md 或 html（不区分大小写），则使用该值。若缺失、无效或已被注释，则静默顺延。关键点：以 # 开头的行属于 YAML 注释，必须忽略——出厂配置模板中包含类似 `# b