需要把多步工作（含非软件任务）拆成可执行…

当你被要求做计划、拆解实现、依据需求出方案或深化已有计划时，用它产出 HOW 层面的结构化计划工件并按契约收尾移交。

适用场景

解决思路

1. 先明确角色分工：ce-brainstorm 定义 WHAT，本技能规划 HOW，ce-work 负责执行；是否已有前置 brainstorm 是可选的，不强制。
2. 显式调用本技能时一定要产出计划：绝不把直接调用判定为「不是规划任务」而路由出去；可以选择下面任一输出契约，最小的有效计划就是聊天里的几句话。
3. 全程只做研究、决策和写计划，绝不实现：不写生产代码、不运行测试、不从执行期结果中学习；允许用方向性伪代码和语法草图沟通设计，但「改代码看会发生什么」属于 ce-work。
4. 遵守强制完成契约：一次运行只有在输出契约的 done 条件满足时才算完成；每个产出计划工件或检查点的正常交互分支，在用户被问到下一步要做什么之前都算未完成，而一个已经授权下一步动作的请求就等于那个答案。
5. Durable 的软件实现计划若越过 resume 检查继续，完成意味着 Phase 5.4 菜单已呈现且所选动作已真正触发；Direct 则要说明变更并给出移交；Chat brief 则在聊天中给出简报和一行「保存或转 ce-work」的提议；后两者都不呈现 Phase 5.4 菜单。
6. 非软件计划和 approach 级计划以其 reference 工作流定义的 handoff 收尾；只回答一个问题的运行可以在回答后结束，除非其 reference 要求保存或分享步骤。
7. 把写文件、检查置信度、运行或显式跳过 ce-doc-review 视为中间里程碑；pipeline 模式下，只有计划、置信度检查和 non-interactive 的文档评审状态都返回给调用方后才算完成，由调用方决定下一步。
8. 交互方式：通过宿主当前工具列表中已有的阻塞式提问工具，一次只问一个问题；按能力匹配，绝不为了发现某个面向用户的工具而去探测它。
9. 若没有列出可用的提问工具，或真实的提问调用报错，就在聊天中渲染编号选项；绝不静默跳过必问的问题；如果未提供功能描述，就问要规划什么并等待。
10. 在 scoping 开始时（Phase 0.6）、选深度之前、做 scoping 综合之前决定适用哪个输出契约；它仅在没有 resume 路由（Phase 0.1）触发且来源检查（Phase 0.2）未发现上游工件时适用。
11. 用对请求所点名内容的有界内联读取来接地输出契约，不要为此派发 subagent。
12. 三选一输出契约：Direct、Chat brief、Durable。
13. Direct：工作能在一遍内说明、完成并验证，且没有用户会权衡的决策——用几句话说明变更，并给出转 ce-work 或交给用户的移交选项。
14. Chat brief：有界工作、最多一个用户会权衡的决策、没有风险面——在聊天中交付后停止。
15. Durable：其余所有情况，继续往下走工作流。
16. 选中 Direct 或 Chat brief 时读 references/output-contracts.md（它定义这两者）；分层仍不确定时取更重的那个；若这次读取暴露出用户会权衡的决策、风险面或多轮验证，在输出任何内容前先升到更重的层级。
17. 无论规模一律判为 Durable 的情形：本回合没有同步用户能响应聊天（pipeline、headless、goal 或 scheduler 驱动）、请求措辞要求计划/计划文件/输出格式、请求延续现有计划的某个条目，以及存在风险面（认证、支付、迁移、外部契约）。
18. 各阶段按顺序执行，除非某个 reference 路由出去或短路；进入某阶段时完整读取该阶段所需的 reference，之前读过的读取不算满足该阶段要求，为最后几步命名的 reference 即使已在上下文中也要在该步骤重读。
19. 如果某个必需的 reference 读不到，就在它管辖的动作之前停下，报告阻塞点和恢复路径；绝不凭记忆重建缺失的规则。
20. pipeline 模式下，任何必需 reference 读取失败都要返回 status: blocked、phase、blocker、recovery_path，存在工件时还要包含 artifact_path 并保留该工件；即使工件存在也报告 blocked。
21. Phase 0 先处理输出：在解释任何阶段之前读 references/output-mode.md，它定义 token 解析、输出与确认的优先级、renderer 选择、工件位置以及何时可以解析仓库。
22. 处理 resume、deepen、approach 和 domain：行动前读 references/resume.md（定义如何恢复已有计划、充实仅含需求的计划、深化、approach 级规划、软件/非软件划分）；若它选中了终止路由就照做，否则继续。
23. 来源与范围：在 Phase 0.2 之前读 references/intake.md 并跟到 Phase 0.7（定义查找并保留上游工件、路由到 bootstrap 工作、阻塞性问题、深度、命名资源、scoping 综合）；上面的输出契约决策就发生在此过程中；不要越过尚未解决的决策点。
24. Phase 1-4：收集上下文之前读 references/research.md（定义本地与外部研究、整合、深度重分类、流程分析、Bake-off 门）。
25. 在解决疑问或组织计划之前读 references/structure.md（定义已定决策的处理、稳定的 U-ID、技术设计、深度、规划边界）。
26. 用 references/plan-sections.md 加上 output-mode.md 选定的格式渲染 reference 来撰写计划内容。
27. Phase 5：写前评审之前读 references/final-review.md（定义 Phase 5.1 到 5.3.2：scoping 综合、写文件、统一计划元数据、置信度模式、深化）。
28. 模型提升：在撰写之前立刻读 references/reasoning-elevation.md，在这个边界解决该选择并照做；在激活解析完成、所选派发或透明回退落定之前不要开始撰写。
29. pipeline 模式下，若证据推翻了本会话早先已定的决策，就停止写入，返回确切 token settled-decision-invalidated、该决策和原因，不要静默解决。
30. 先写计划再呈现选项，然后走完 final-review.md 定义的置信度路径。
31. 在 Phase 5.3.8 和 5.4 之前立刻读 references/plan-handoff.md（文档评审与 handoff 菜单）：Durable 计划的文档评审是强制的，默认非交互（mode:non-interactive）。
32. 交互式软件运行中，精确询问："Plan ready at `<absolute path to plan>`. What would you like to do next?"，呈现其菜单并等待；若选择在某个用户回合之后才到达，行动前重新加载 references/plan-handoff.md。
33. 渲染菜单、收到选择或宣布路由都不算完成；必须真正执行所选动作。

适用边界 · 注意事项

• 只做探索性框定、还没想清楚要做什么（WHAT）时，用 ce-brainstorm，不要用本技能。
• 需要真正落地——写生产代码、跑测试、根据执行结果迭代——时属于 ce-work，不适用本技能。
• 必需的 reference 文件读不到时，不要凭记忆重建规则继续执行，应先停下并报告阻塞与恢复路径。