ce-work

工作执行命令

初始设定

在本次调用的最开始（任何子 Agent 调度之前）运行一次此脚本，并遵循其输出的指令——除非其中某条指令与本 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

执行结果

• 结果： 根据计划、规格或具体工作提示词完成的完整实作与本地验证变更集。
• 后续承接方： 在独立使用模式下，发布工作流程会接手经过验证的变更并进行审查与交付。在返还调用方模式（Return-to-Caller Mode）下，发起调用的工作流程会接收到结构化的实作与验证封包，并接管后续的闸口控制。
• 完成标准： 范围内的各项任务均已完成、录入必要的验证依据、相关检查全部通过，且此运行流程已成功移交至其负责的发布阶段、生成完整的返回封包，或遇到明确的阻碍事项（blocker）。
• 设计初衷： 在不重新协商计划或移交规范整合控制权的前提下完成所需功能。Worker 只接收有界的任务单元；主协调器负责审查实际变更，并拥有权威验证与规范 Commit 的控制权。

输入文件

本次运行的输入文件即为调用本 Skill 时传入的输入——存在于当前提示词或对话中，无论是由使用者直接提供，或是由调用的 Skill 传递（例如在 mode:pipeline 下传递计划路径的 lfg）。可以是一个计划或规格路径、跟随路径的 mode: 标记，或者是一个纯工作提示词。本 Skill 的后续内容将其统称为 <input_document>；若未提供任何内容，请将 <input_document> 视为留空。

调用的来源不可见亦无关紧要：无论使用者是明确调用 ce-work 还是由宿主自动选择，均套用相同的来源解析规则。

工件根目录

本 Skill 会在 <root>/plans/ 下寻找计划，并可能在 <root>/residual-review-findings/ 下写入审查残留结果。请在首次组装 <root>/ 路径时（依据下方区块）解析 <root>，切勿过早解析。无论是向 <root>/... 写入资料还是读取 <root>/solutions/，均算作组装 <root>/ 路径，因而都会触发解析；只有完全不触及 <root>/ 路径的运行（例如仅使用暂存区或无 Git 储存库的流程）才会跳过解析；请将解析后的路径传递给任何子 Agent，而非传递设定档。

<!-- 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，与此前完全一致。
• 验证已设定的值：必须是储存库内的相对目录，且经过 Symlink 解析后的真实路径仍保持在储存库内部，既不能是储存库根目录，也不能位于 .git/ 下。否则停止并报错说明 docs_root 及其设定的值——绝不自动倒回（fall back）使用 docs。
• 使用 <root> 作为唯一的工件存放位置：若不存在则建立，并将各个路径组装为 <root>/<subdir>（搭配本 Skill 的子目录），绝对不要同时读取 docs。
  <!-- ce-docs-root:end -->

执行工作流程

内建参考文件的加载策略为“预设拒绝”（fail-closed）。 下文提到的每个内建参考文件或脚本路径，都必须从本 Skill 已加载的 SKILL.md 所在目录进行解析（使用 Harness 提供的 Skill 完整路径）；绝对不要在目标储存库中以 Glob 匹配去寻找内建文件。若 Harness 未暴露该目录，或无法读取所需文件，请在受其约束的动作前停止并回报缺失的参考文件，而不是去推测粗估协定或原生继续执行。

阶段 0：输入分流

复原机制优先启用。 在进行一般的计划、路径、空白输入或纯提示词分类之前，首先判断使用者是否在语意上要求恢复、检查状态、收割（reap）或清理现有的外部实作运行流程，且已提供其运行 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）：首先是一个紧凑型 JSON 物件，前缀必须精确为 implementation_engine:；其次是一个运行 ID，前缀必须精确为 implementation_run:。引擎物件仍作为型别化的调用方绑定，且必须精确包含 mode、target、model 和 source，其型别与数值如 references/execution-engines.md 所定义；运行承载器仅在 return-to-caller 复原时被接受，且必须满足上述 safe-id 规范。格式错误 JSON、缺失/多余栏位、不安全的运行 ID 或重复的承载器均应予以拒绝。剥离后剩余的整个字串即为计划路径。若只有 mode 标记或承载器而无后续路径则视为错误；请直接回报错误，不要将控制资料当成纯提示词处理。在没有任何可选承载器的情况下，原本的 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 前的探索属于唯读操作。在解析绑定与初始化外部 Controller 之前，切勿在规范检出（canonical checkout）中运行基线、测试、建置、格式化、安装或生成命令：因为在 Controller 记录其干净起点之前，这些命令可能会建立被忽略或未追踪的工件。请将分流仅限制在读取操作，例如元资料、原始码、设定档、分支、状态以及命令可用性探测。若确实需要非读取探查来决定路线是否可以启动，请务必开启工件抑制功能运行，并在继续之前证明规范 Git 快照位元组级别（byte-for-byte）未受变更；否则请停止并报路线阻隔。

在空白输入或纯提示词分类之前，先解析会话中携带的计划。 当当前请求为“继续”等延续性语言，且对话中能明确识别出专为此项工作撰写、选择或接受的唯一当前计划/规格路径时，请将该路径视为 <input_document>。若有多个会话计划皆有可能，请询问使用者欲使用哪一个；切勿按时间顺序盲目选择最新者。切勿用不相关的前期计划替代具体的新工作请求。此规则仅取决于可见的对话状态，与调用是明确发起还是自动触发无关。

每一个非复原代码路线在执行前都必须解析其实作引擎。 一旦元资料或提示词分流识别出代码工作，在读取活跃实作单元、建立任务、写入文件或提交之前，请先阅读 references/execution-engines.md 并执行其路线解析闸口。无论是否存在 implementation_engine: 承载器均适用此规则：若存在 .compound-engineering/config.local.yaml，请进行检查，因为既有设定在独立模式与无承载器的 Return-to-Caller 模式下均有效。在路线解析闸口排除或合法耗尽适用的更高权限路线之前，切勿选择内联/原生（inline/native）执行。

根据 <input_document> 传递的内容（在剥离任何 mode 标记之后）决定如何继续。

计划文件（输入为现有计划或规格的文件路径）：首先读取计划的元资料——Markdown 计划读取 YAML frontmatter，HTML 计划则读取可见标头文字（两种格式带有相同的栏位）。

• 若带有 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（Phase 1）。
  • 任何其他准备状态值或任何非代码/未分类执行模式 -> 切勿自动作为代码执行。将 execution: knowledge-work 导流至非代码特殊流程；否则请要求使用者返回 ce-plan 以产出准备好实作的代码计划。
  • 类似进度的值（active、in_progress、completed、done）均属于无效的准备状态值。请停止并要求修正计划，而非盲目猜测。
• 若带有 execution: knowledge-work，此为非代码计划——请读取 references/non-code-execution.md 并遵循该特殊流程，而非本工作流程的其余部分。
• 否则（旧版计划、栏位缺失或 execution: code）-> 继续进入阶段 1（Phase 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 丰富化步骤。被替代的同级计划： 若...

<!-- truncated for translation batch; full body continues in source -->