当需要把模糊或宏大的功能想法在动手前梳理成仅需求…

用户想头脑风暴或界定要构建什么时，用对话产出聊天结论或仅需求统一计划，而不是执行已明确的工作。

适用场景

解决思路

1. 通过对话回答 WHAT 要构建什么；`ce-plan` 随后用 HOW 丰富同一个统一计划制品；本技能不实现代码。
2. 当前年份是 2026，用其为制品标注日期。
3. 产出结果要与工作规模匹配，使 `ce-plan` 无需虚构产品行为、范围边界或成功标准即可在其上构建：Lightweight 工作给聊天段落；当值得写文件时，在 `<root>/plans/` 下写仅需求的统一计划。
4. 在头脑风暴路径上，完成条件是：制品已写出并通过 Ready for Planning Check；或者未写文件，因为对话没有产生后续读者需要在稳定 ID 下记录的决定，且用户也未要求；然后呈现 Phase 4 的交接。
5. Lightweight 工作在聊天中结束。Phase 0.3 在派发任何东西前，根据请求和有界的内联阅读分类层级；层级不确定时取更重的。
6. Lightweight 工作（小、边界良好、低歧义）以聊天段落结束：不写文件、不派发 grounding scout、不生成 approach、不运行 claim verifier。
7. 只有在某个决定需要后续读者在稳定 ID 下记录，或用户主动要求文件时，才值得写文件。
8. 有三种情况要停止并转路由，依据 `references/phase-0.md` 而不是凭记忆决定；每种以自己的方式结束，上述完成条件不适用。
9. 非软件工作：用 `references/universal-brainstorming.md` 替换 Phases 0.2–4。
10. 对已命名外部候选的裁决问题：提供 `ce-pov` 交接。
11. 二者都不是：快速帮助、事实问题、单步任务，直接回答。
12. 功能描述来自调用时携带的内容，无论用户写还是调用技能传入；如果没有，询问用户想探索什么，并在得到之前不要继续。
13. 处理 `mode:return-to-caller`：如果调用技能如 `lfg` 设置了该前导 token，去掉它，原样运行对话，并将 Phase 4 替换为 `references/handoff.md` 定义的结构化返回：不显示菜单，不调用 `lfg` 或 `ce-plan`。
14. 在第一次组合或读取 `<root>/` 路径时解析 `<root>`，绝不提前；仅 scratch 或无仓库运行且不触及任何 `<root>/` 路径时可完全跳过。
15. 解析 CE 制品根 `<root>`：从 `<repo-root>/.compound-engineering/config.yaml` 读取 `docs_root`（仅这个文件），`<repo-root>` 用 `git rev-parse --show-toplevel` 获取；不要从 `config.local.yaml` 读取。未设置则 `<root>` 为 `docs`，与之前完全相同。
16. 校验已设置的 `docs_root`：必须是仓库相对目录，其真实、解析符号链接后的路径留在仓库内，且既不是仓库根也不是 `.git/` 下；否则以错误停止，错误需指出 `docs_root` 和值——绝不回退到 `docs`。
17. 将 `<root>` 作为唯一制品位置：若不存在则创建；每个路径组合为 `<root>/<subdir>`，使用此技能自己的子目录；绝不同时读取 `docs`。
18. 解析 `brainstorm_output` 和 `brainstorm_model` 使用另一规则：先读 `<repo-root>/.compound-engineering/config.local.yaml`，再读 `config.yaml`（`<repo-root>` 同上）；缺失文件跳过；gitignore 不改变解析。
19. 上述配置解析中，以第一个生效（非注释）值获胜；对标量，空值视为未设置；无效值继续到下一层，然后技能默认值；对列表和映射，键存在——包括空列表或空映射——会替换整个键。
20. 不要对 `docs_root` 使用该配置层规则——该键只能来自 `config.yaml`。
21. 按顺序运行各阶段；每个阶段列出其无法在缺少文件时正确运行的依赖：到达该阶段时读取这些文件，绝不仅凭执行流表做该阶段工作。
22. 在第一个问题之前，以及整个运行中（包括非软件路线）先读 `references/interaction-rules.md`；它承载核心原则和交互规则：每轮只问一个问题，只问环境无法解决的决定，默认使用 blocking-question-tool 以及覆盖它的 visual-probe gate，何时问题是真正开放式的，以及此技能完整陈述的一个 `ce-prototype` 路由测试。
23. 在把对话携带的决定视为已定之前，读 `references/settled-decisions.md`；它承载 settlement test；跳过会重新询问已决定的问题，或提升未经检验的断言。
24. 0.0 输出模式：读 `references/output-mode.md`；它承载 `OUTPUT_FORMAT` 优先级和 token 解析约定。
25. 0.1–0.4 恢复、分类、路由、范围：读 `references/phase-0.md`；它承载恢复扫描；停止并转路由分类；范围层级；coherent-work gate（这是一件工作吗？）；两个 tripwire（视觉或空间功能；不熟悉领域）；任务列表。
26. 1 理解想法：读 `references/dialogue.md`；它承载上下文扫描和 grounding scout；可选加入 Slack researcher；压力测试；盲点与 visual-probe gate；针对现有 `CONCEPTS.md` 和已验证代码的冲突门；Phase 1.3 退出条件。
27. 2–2.6 方法、综合、验证：读 `references/approaches.md`，并在撰写综合之前读 `references/synthesis-summary.md`；它承载方法生成；模型提升；范围综合；claim verifier。
28. 3 写计划：读 `references/plan-write.md`，然后读 `references/brainstorm-sections.md` 和用于该格式的渲染参考；它承载是否值得写文档；章节契约；Ready for Planning Check。
29. 4 交接：读 `references/handoff.md`；它承载选项集及其可见条件；渲染模式规则；按选择派发，包括传给 `ce-plan` 什么；结束摘要。
30. 以下规则无需任何读取即生效：`OUTPUT_FORMAT` 是排他性的——markdown 或 HTML，绝不要两者都有。格式取第一个适用者：本提示中的请求、用户早先声明的偏好、配置，然后 markdown；在包括 headless 的每次运行中都如此。
31. 当在头脑风暴路径上写文件时，制品契约不变：写入 `<root>/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.<md|html>`，其中 `HHMM` 取写入时的本地墙钟时间；frontmatter 包含 `artifact_contract: ce-unified-plan/v1` 和 `product_contract_source: ce-brainstorm`；正文是 Goal Capsule 加 Product Contract。不要输出 Goal Launch Block 或 Reader Index。非软件路线不写这些。
32. 当文件已写出时，只要 Ready for Planning Check 中任一检查失败，就不要声明已写出或进入 Phase 4；聊天结果直接进入 Phase 4（交接），无需运行检查。
33. 不要临时拼凑交接菜单——这是另一种静默失败：它会显示本应隐藏的选项，并把错误输入传给下一个技能。
34. Phase 1.1 grounding scout、Phase 2.6 claim verifier 和可选 Slack researcher 按任务形态分层，绝不硬编码到模型名；派发其中一个之前读 `references/model-tiers.md`。模型提升是单独机制（`references/reasoning-elevation.md`）。

适用边界 · 注意事项

• 不适用于执行已经明确规格的工作；本技能不实现代码。
• 不适用于非软件工作；应使用 `references/universal-brainstorming.md` 替代 Phases 0.2–4。
• 不适用于对已命名外部候选技术做采用裁决（应转 `ce-pov`），也不适用于快速帮助、事实问题或单步任务（应直接回答）。