需要无人值守端到端完成请求时，用 lfg 通过…

当用户明确要求自主端到端工作或直接调用 lfg 时，按请求形态路由到正确的 Compound Engineering 技能并一路执行到完成，代码改动结束为已推送的开放 PR。

适用场景

解决思路

1. 先根据请求形态确定应达到的最终状态：多数请求以对应 Compound Engineering 技能的结果结束且不建分支；代码改动则结束为开放 PR，持有其 URL，CI 已判定，且已完成实现、简化、应用合格审查发现并记录其余发现、捕获持久学习、提交和推送；除非用户本次授权，合并仍留给用户。
2. 在会改变代码的路由上，没有本次运行验证通过的工作源就不得实现；只有两种工作源合格：实现就绪的计划（由 ce-work 实现）或 ce-debug 返回的 fixed（该修复就是实现）。
3. 工作源中的计划必须由会话自行识别，按 references/intake.md 定义；不要搜索 plans 目录找候选，也不要对发现的文件采取行动；不要基于已有计划从头规划。
4. 按请求内容匹配到职责对应的技能；host 的技能列表是技能目录。选择路由前先读 references/intake.md，因为该文件单独定义路由、优先级、传给各子技能的内容以及如何解读每个返回。
5. 若请求是计划路径，或计划由 ce-plan 在本次会话写出，则走计划路由。
6. 若请求是具体报告失败或错误行为，则交给 ce-debug；复现是 ce-debug 的职责，不是 intake 的职责。
7. 若改动依赖用户尚未解决的判断，则先交给 ce-pov；只有支持该改动的裁决才继续，没有可构建内容的判断止于该裁决。
8. 若产品形态存在多于一种合理解读，且人在场，则交给 ce-brainstorm；若无人（pipeline 模式），则交给 ce-plan。
9. 若请求结果不是代码改动，则交给拥有该结果的技能（如 ce-explain、ce-prototype、ce-pov、ce-ideate 等）；该调用就是整个运行：返回其结果并结束。
10. 任何其他代码改动交给 ce-plan。
11. 不确定时，选择对证据要求更高的路由。
12. 只通过 ce-brainstorm 向用户提问，且仅在人在场时。其他一切无需等待：可逆工作直接完成并展示，供用户事后纠正；只有超出授权的不可逆操作（未授权的合并、force-push、删除数据）才停下。
13. lfg 可从调度器、循环和嵌套编排器中运行。
14. 当对话把规划或实现分配给模型或 harness 时，路由前读 references/stage-routing.md；该文件单独包含 carrier strings 和 sanitization，是唯一的路由消歧依据。
15. 遇到以下情况时停止并说明原因：工作源无法产生（规划返回 blocked、诊断未找到安全修复、修复会发散、ce-pov 不支持改动、阶段分配无法传递）；子技能返回不是 complete 且有证据；已定决策失效；项目定义的发布流程不足。
16. 停止时，不要推送任何尚未推送的内容。
17. 针对 host 的 available-skills 列表解析本技能命名的每个技能，并调用完全匹配条目；某些 host 会加命名空间（如 compound-engineering:ce-plan）。
18. 开始前读 references/task-visibility.md；按其定义通过平台任务跟踪能力发布阶段视图和聊天叙述，并遵守完成规则：一步只有运行后才算完成；子技能返回后在同一轮恢复下一个编号步骤；在 DONE 或停止前不要结束该轮。
19. 代码改动运行的第 1 步：按 references/intake.md 产生工作源。计划路由先读 references/plan-brief.md，该文件单独定义 settled-decisions brief 和 artifact-root 规则。任何显式 status: blocked 返回（包括 settled-decision-invalidated）都停止运行；blocked 状态优先于已有 artifact，且永不重试。仅当 blocker 和 ce-plan 本次报告写出的计划文件都不存在时，才用同样参数第二次调用 ce-plan，并逐字复用已组合的 brief；随后计划必须通过 references/plan-brief.md 的就绪检查。计划路由上当 planning-stage 指令已解析时，让 plan_model:<alias> carrier 随请求传递。为后续每一步记录工作源。LFG 永不直接启动 /goal；ce-work 掌管任何 goal-mode 选择并返回控制。
20. 代码改动运行的第 2 步：先读 references/work-return.md，然后以 mode:return-to-caller <plan-path-from-step-1> 调用 ce-work 技能。缺陷路由不运行此步：ce-debug 已实现并提交，references/debug-return.md 是其门禁。只有有效的 status: complete 可推进；其他任何状态或畸形返回都停止流水线。
21. 代码改动运行的第 3 步：现在读 references/review-followup.md；它管辖步骤 3 到 7。对分支 diff 调用 ce-simplify-code 技能；仅对 docs-only 或大约少于 10 行的改动跳过该调用。
22. 代码改动运行的第 4 步：以 mode:agent plan:<plan-path-from-step-1> 调用 ce-code-review 技能；缺陷路由省略 plan:。若 settled_conflict 发现的证据显示已定决策不可行、错误或破坏性，则在 shipping precondition 之前作为 blocked 停止流水线，并报告该发现。
23. 执行 shipping precondition（从第 5 步起的每次 push）：运行 git remote 一次。无 remote 表示仅本地：执行各步骤要求的所有 commit，但跳过每次 push、PR 创建/编辑和 CI-watch 动作，包括完全跳过第 10 步。这是终止态，不是错误。
24. 代码改动运行的第 5 步：按 references/review-followup.md 定义应用并持久化审查修复。当合格审查修复仍只在工作树中未提交时，不要进入 residual handoff、运行浏览器测试或输出 DONE。
25. 代码改动运行的第 6 步：自动 residual handoff。只要存在未应用的可操作发现、第 4 步的 settled_conflict 标记，或第 2 步中 proceeded-and-flagged 的 settled_decision_conflicts 条目，就按该文件持久记录：写入 PR 正文，或当不会存在 PR 时写入 tickets 或 DONE 报告。仅当三者都不存在时跳过。在 residuals 持久化前不要输出 DONE。一旦报告说明了 tracker filing failures，永不因它们阻塞 DONE。不要提示用户。
26. 代码改动运行的第 7 步：当运行产生了代码、测试和计划未承载的持久推理时，以 mode:non-interactive 调用 ce-compound 技能；该文件说明完整条件。Documentation skipped 是成功；在此运行会把学习放入开放中的 PR。
27. 代码改动运行的第 8 步：以 mode:pipeline 调用 ce-test-browser 技能。
28. 代码改动运行的第 9 步：先读 references/shipping.md；它管辖步骤 9 到 11。然后以 mode:pipeline branding:on 调用 ce-commit-push-pr 技能。
29. 代码改动运行的第 10 步：当开放 PR 存在时，按 references/shipping.md 决定，用 ce-babysit-pr mode:pipeline <pr-url> 监视 PR 直到 CI 判定。不要在此重新实现 CI-watching。
30. 代码改动运行的第 11 步：按 references/shipping.md 的 close-out 后输出 <promise>DONE</promise>。

适用边界 · 注意事项

• 用户希望逐步审查工作时，用 ce-plan、ce-work、ce-debug 或 ce-commit-push-pr 等技能，而不是 lfg。
• 用户未明确要求自主端到端工作且未直接调用 lfg 时，不要使用。