按计划/规格实施并本地验证时用：完成实现、验证和交接口…

当你已有计划文档、规格路径或明确构建请求，需要端到端完成实现与本地验证，并将后续 shipping 或剩余 gate 交给 shipping workflow 或调用方时使用。

适用场景

解决思路

1. 读取 bundled references：从本技能加载的 SKILL.md 目录解析每个列出的 reference 或 script 路径，使用 harness 提供的完整技能路径；绝不 glob 目标仓库来查找 bundled 文件。进入治理该阶段的相位时再读对应 reference；在相位之前读的不算；文件要求重读时，即使已在上下文中也要在该步骤重读。若 harness 不暴露技能目录，或必需文件无法读取，在被该文件治理的动作前停止并报告缺失哪个文件；不要凭记忆重建规则，改报缺失 reference，不要继续原生执行。
2. 恢复激活优先：在把输入分类为 plan、path、blank 或 bare prompt 之前，先识别恢复、检查、回收或清理已有 run 的请求。Recovery 绝不 dispatch 新 worker、选择新路由、发现另一个 plan、重跑已完成验证或进入任一 shipping path。若缺 run id，询问它，绝不猜测。
3. 在任何其他输入决策前，读 references/input-triage.md；用它决定 source resolution、control tokens、recovery、read-only discovery、plan readiness、non-code routing、blank input、bare-prompt sizing。
4. 对 Trivial bare prompt：若只涉及一两个文件且无行为变更，跳过 task list，但仍在写入前 resolve execution engine。纯机械 diff 也无需 post-PR watch 就 ship。任一情况不确定时，走更完整路线。
5. 若 bare prompt 已由 ce-plan 在本 session 定尺寸，直接执行，不要再次规划。用户会权衡的决策以问题形式询问，不要作为回 ce-plan 或 ce-brainstorm 的路由。
6. 若 references/input-triage.md 无法读取，停止；绝不把 control tokens 或不可执行 artifact 当作代码工作。
7. 当 triage 选择 Return-to-Caller Mode，立即读 references/return-to-caller.md，并记录它治理本次 run 如何结束。若无法读取，在任何 mutation 前停止；不要回退到 standalone 行为。
8. 建立 workspace：在移动分支、编辑、dispatch 或 commit 前，读 references/workspace-setup.md；用它决定 writable checkout、plan clarification、branch placement、pre-work inventory、already-dirty files、task setup。没有 writable canonical checkout 绝不写入；除非用户在本 session 明确指示，绝不在真实默认分支上写入。
9. 不要 commit 或 publish 用户未提供的东西。当某 unit 需要已经 dirty 的文件时，standalone mode 问一次是否 include 或 exclude 该文件；Return-to-Caller Mode 既不询问也不编辑它，而是返回 blocked，命名冲突及恢复方式。
10. 完成 bounded plan intake 和 task derivation 后，但在选择 unit 执行、写入、dispatch 或 commit 前，读 references/execution-engines.md 并完成其 route selection。无论是否有 typed binding 都适用；只有该 reference 选择 native execution 或耗尽允许的 fallback 时，native execution 才可用。引擎选择绝不改变哪个 reference 治理 run 如何结束。
11. 若选择 cross-model execution，在任何内容或权限跨到另一模型前，读 references/cross-model-execution.md；它定义 controller initialization、post-init engine lock、bounded egress、transactions、recovery、receipts。
12. 在选择 inline、serial 或 parallel execution 前，且在 dispatch 任何 worker 前，读 references/execution-strategy.md；它决定 scheduling、isolation、每个 worker 收到的 packet、worker lifecycle、integration。Host orchestrator 保留权威验证并做 canonical commits。
13. 在首次实现写入前，包括 Trivial 路线，读 references/implementation-loop.md；它决定 evidence 如何选择、验证、何时停止 unit、incremental commits、遵循现有 patterns、continuous testing、simplification 停在哪里、UI work、progress tracking、settled decisions。
14. 执行 commit 规则：每个 implementation commit 只命名该 unit 拥有的文件。禁止裸 git commit，因为它会吸收用户已有的 index。
15. 在 tasks 和 local verification 完成后，standalone mode 在任何 quality check 或 delivery 前读 references/shipping-workflow.md；它决定 simplification、code-review receipts 和 fallbacks、leftover findings、final validation、delivery。
16. 执行 code-review completion gate，仅 standalone：在 shipping reference 记录实际完成的 ce-code-review receipt 或其 exact authorized skip states 之一之前，code review 必须实际发生；否则 run 未完成，不得调用 commit 或 shipping skill，也不得报告 shipping complete。绝不用 mental self-review 或 earlier applied findings 替代。此规则不适用于 Return-to-Caller Mode。
17. 在 Return-to-Caller Mode 中只做 implementation 和 local verification；不得进入 Phase 3-4 或运行 final simplification、code review、PR creation、CI watching、babysitting 或任何其他 standalone shipping action，由 caller 拥有这些步骤。
18. 在发出 Return-to-Caller 结果前，立即再次读 references/return-to-caller.md；只有它定义完整 return result、evidence complete check、route and model records、recovery semantics 和 standalone_shipping_skipped: true。不要从本文件构建完整结果。
19. 如果该必需读取在 planning 或 implementation 已创建 state 后失败，保留每个 changed file、commit、workspace 和 controller record。返回本文件的最小 blocked result：status: blocked、plan_path、run_id when known、changed_state、blockers 命名缺失 reference、recovery_path。不要擦除 partial state、报告 success 或落入 standalone shipping path。
20. 完成后验证结果：得到从 plan、specification 或具体 work prompt 产生的 fully implemented、locally verified change set。
21. 交接：standalone 使用中，shipping workflow 接管 verified change 进行 review 和 delivery；Return-to-Caller Mode 中，调用方 workflow 收到结构化 implementation 和 verification result，并拥有剩余 gates。
22. 完成标准：每个 in-scope task 完成，所需 verification evidence 已记录，相关 checks 通过，run 达到其拥有的 shipping handoff，带 code-review receipt 或明确 skip phrase，见 Phase 3-4，或达到完整 return result，或达到明确 blocker。
23. 保持意图：完成请求的 feature，不重新协商 plan 或转移 canonical integration authority。Workers 收到 bounded units；host orchestrator 检查实际 changes 并拥有 authoritative verification 和 canonical commits。

适用边界 · 注意事项

• 开放式、未明确的 bug 调试不适用；应使用 ce-debug。
• 需要完整 shipping 尾部（最终简化、代码评审、PR creation、CI watching、babysitting 等）时，不要在 Return-to-Caller Mode 下使用；该模式明确跳过这些动作。
• harness 未暴露技能目录或必需 bundled reference 无法读取时，不应继续执行；应停止并报告缺失文件。