ce-work

Work Execution Command

Setup

在本次调用的开头、调度任何 Subagent 之前运行此脚本一次，并遵循其输出的指令——除非指令与本 Skill 自身关于询问用户的规则产生冲突（无论该规则仅适用于非交互模式还是适用于所有模式），此时本 Skill 的规则优先，不会发起阻塞式提问。请勿在同一次调用中重复运行；后续调用本 Skill 或其他 Skill 时会运行各自的脚本。若环境中没有 Node 运行时，Skill 将保持原有行为继续执行。

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi

Outcome

• Result: 基于方案、规范说明（spec）或具体开发 Prompt 完成实现并经过本地验证的变更集。
• Next consumer: 在独立使用模式下，交付工作流（shipping workflow）将引导通过验证的变更完成评审与发布；在返还调用方模式（Return-to-Caller Mode）下，发起调用的工作流将接收结构化的实现与验证信封数据（envelope），并掌控剩余的关卡卡口。
• Done: 作用域内的所有任务均已完成，录入了所需的验证凭证，相关检查均已通过，且运行已到达其负责的交付交接点、完整的返还信封，或显式的阻塞点（blocker）。
• Intent: 在无需重新协商方案或转移主集成权威的前提下完成请求的功能开发。Worker 接收有界的工作单元；宿主编排器（host orchestrator）检查实际变更，并拥有权威验证与主 Commit 的所有权。

Input Document

本次运行的输入文档即为调用本 Skill 时传入的输入——存在于当前 Prompt 或对话中，无论是由用户直接提供，还是由上游调用 Skill 传递（例如 mode:pipeline 下传入方案路径的 lfg）。它可以是方案或 spec 的路径、后跟路径的 mode: 标记，或者一段纯文本开发 Prompt。本 Skill 的后续部分统一将其简称为 <input_document>；若未提供任何内容，则将 <input_document> 视为空白。

调用的来源方式不可观测也不相关：无论是用户显式调用 ce-work 还是由宿主自动选择，均应用相同的来源解析规则。

Artifact Root

本 Skill 会在 <root>/plans/ 下探索方案，并可能将评审残留结果写入 <root>/residual-review-findings/。在首次拼接 <root>/ 路径时（参考下方规则块）解析 <root>，绝不要提前解析。写入 <root>/... 或读取 <root>/solutions/ 均属于拼接 <root>/ 路径的操作，两者都会触发解析；只有完全不触碰任何 <root>/ 路径的运行（如纯临时/无 Repo 流程）才会跳过解析；请将解析后的路径传递给所有 Subagent，而非传递配置。

<!-- 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，与此前完全一致。
• 校验已设置的值：必须是相对于仓库的目录路径，且其符号链接解析后的真实路径保留在仓库内部，既不能是仓库根目录，也不能在 .git/ 下。否则报错停止并指明 docs_root 及其具体值——绝不回退至 docs。
• 使用 <root> 作为唯一的制品存储位置：若不存在则创建，按 <root>/<subdir> 拼接每个路径（包含本 Skill 自身的子目录），且切勿同时读取 docs。
  <!-- ce-docs-root:end -->

Execution Workflow

内置引用加载采用失败闭合（fail-closed）机制。 下文提到的每个内置引用或脚本路径，都必须基于 Harness 提供的本 Skill 已加载 SKILL.md 所在目录进行解析；绝不能通过在目标仓库中执行 Glob 通配符查找来定位内置文件。若 Harness 未暴露该目录，或无法读取所需文件，必须在受其约束的操作之前停止，并报告缺失的引用，而不能近似推测协议或自行继续执行。

Phase 0: Input Triage

优先处理恢复激活（Recovery activation）。 在进行常规的方案、路径、空白输入或纯 Prompt 分类前，先解读用户语义上是否要求恢复、查看状态、收割或清理现有的外部实现运行（external implementation run），且是否提供了其运行 ID（run id）。这是意图识别，而非仅匹配动词。使用 Controller 的 safe-id 契约校验该 ID：^[A-Za-z0-9._-]{1,128}$ 且至少包含一个非句点字符。当存在此直接恢复意图时，读取 references/cross-model-execution.md，将该运行 ID 作为请求 Controller 操作的权威凭据，并返回观测到的状态或阻塞点。恢复流程不得派发新的 Worker、选择新路由、落入最新方案探索，或运行任何交付尾端流程。当所有单元均已清理完毕时，已完成的恢复属于仅读对账（read-only reconciliation）：请勿重新运行测试、构建、格式化、安装、生成或 verify-run；仅需报告已记录的单元及全方案验证收据。如果恢复意图明确但缺失运行 ID，请提示索取 ID，而非盲目猜测或将其误分类为新工作。

否则，解析前导 mode 标记。 若 <input_document> 以 mode:return-to-caller（或旧版别名 mode:caller-owned-tail / caller:lfg）开头，请首先剥离该标记并进入返还调用方模式（Return-to-Caller Mode）（参见 § Return-to-Caller Mode）——仅进行代码实现与本地验证，然后返回结构化信封数据，而非运行独立的交付尾端流程。在方案路径之前，允许按以下固定顺序传入最多两个可选载体（carrier）：首先是以 implementation_engine: 为精确前缀的紧凑 JSON 对象，其次是以 implementation_run: 为精确前缀的运行 ID。Engine 对象保持为类型化的调用方绑定（caller binding），且必须精准包含 references/execution-engines.md 中定义的 mode、target、model 和 source 及其对应的类型和值；Run 载体仅在返还调用方恢复场景下被接收，且必须符合上述 safe-id 契约。若 JSON 格式错误、缺失/多出字段、运行 ID 不安全或存在重复载体，均应予以拒绝。剥离后剩余的整段字符串即为方案路径。若存在 mode 标记或载体但后续无路径，则视为错误；应报告错误，而非将控制数据当作纯 Prompt 处理。若未提供任何可选载体，原有的 mode:return-to-caller <plan-path> 格式保持不变，现有配置依然适用。

当存在 implementation_run:<safe-id> 时，恢复流程优先于常规输入分类：读取 references/cross-model-execution.md，使用 resume --run-id <safe-id> 作为权威入口点，并在对账后返回标准的 Return-to-Caller 信封数据。若同时提供了 implementation_engine 绑定，请予以保留。切勿解析其他路由、重新派发、重新实现、重复运行已完成的验证或开启另一个调用方尾端。

当存在有效的 implementation_engine: 绑定且无恢复意图时，Controller 启动前的探索过程为纯读操作（read-only）。在解析绑定并初始化外部 Controller 之前，切勿在主工作区（canonical checkout）中运行基线、测试、构建、格式化、安装或生成命令：这些命令可能会在 Controller 记录干净起始点之前产生被忽略或未跟踪的制品。将预检限制为元数据、源码、配置、分支、状态以及命令可用性探针等读取操作。若确实需要非读取探针来判定路由能否启动，仅可在抑制制品生成的前提下运行，并在继续之前证明 Git 主快照在字节级别保持完全未变；否则停止并抛出路由阻塞。

在进行空白或纯 Prompt 分类之前，先解析会话中携带的方案。 当当前请求属于“继续（proceed）”等续作表述，且对话上下文中能精准锁定一个为本次工作创建、选择或接受的当前方案/spec 路径时，将该路径作为 <input_document>。若有多个合理的会话方案，请询问用户指定哪一个，切勿按时间最近原则盲目选择。切勿用不相关的早期方案替换具体的新工作请求。本规则仅取决于可见的对话状态，与调用方式是显式还是自动无关。

所有非恢复代码路径在执行前都必须解析其实现引擎（implementation engine）。 一旦元数据或 Prompt 预检判定为代码工作，但在读取活跃实现单元、创建任务、写入文件或提交之前，必须读取 references/execution-engines.md 并执行其路由解析卡口（route-resolution gate）。无论是否带有 implementation_engine: 载体均适用：若存在 .compound-engineering/config.local.yaml，请对其进行检查，因为在独立模式和无载体的 Return-to-Caller 模式下，现有配置依然有效。在卡口排除或合规消耗掉适用的更高权威路由之前，切勿选择内联/原生执行。

根据 <input_document>（剥离 mode 标记后）提供的内容确定下一步操作：

方案文档（Plan document）（输入为现有方案或 spec 的文件路径）：首先读取方案的元数据——Markdown 方案读取 YAML frontmatter，HTML 方案读取可见的 Header 文本（两种格式包含相同的字段）。

• 若带有 artifact_contract: ce-unified-plan/v1，在读取正文前先对 artifact_readiness 进行分类。
  • artifact_readiness: requirements-only -> 停止并告知用户该产品契约（Product Contract）在实现前需要通过 ce-plan 进行补充完善。提供准确的 ce-plan <plan-path> 交接建议。
  • artifact_readiness: implementation-ready 且 execution: code -> 使用下方的统一方案读取策略继续进入阶段 1。
  • 其他任何 readiness 值或任何非代码/未分类的执行模式 -> 切勿自动作为代码执行。将 execution: knowledge-work 路由至非代码例外流程（non-code carve-out）；否则请用户返回 ce-plan 以生成就绪的代码实现方案。
  • 类似于进度的值（如 active、in_progress、completed、done）均为无效的 readiness 值。停止并要求修复方案，而非盲目猜测。
• 若带有 execution: knowledge-work，则此为非代码方案——读取 references/non-code-execution.md 并遵循该例外流程，而非本工作流的其余部分。
• 否则（旧版方案、字段缺失或 execution: code）-> 继续进入阶段 1 并运行正常的代码生命周期。

空白调用的最新方案探索： 当 <input_document> 为空时，Glob 匹配 <root>/plans/*.md 与 <root>/plans/*.html，检查最新候选文件的元数据，且仅自动选择 artifact_readiness: implementation-ready 且 execution: code 的方案，或旧版代码方案。若最新的匹配制品为仅限需求（requirements-only）、execution: knowledge-work、思路方案（approach-plan）或未分类的通用/问答类输出，请停止执行而非静默运行。要求提供明确路径或进行 ce-plan 补充步骤。被替代的同级方案： 若...