relay

输入

• 环境：RELAY_SKILL_ROOT 为可选项，默认为 skills；可通过 RELAY_ORCHESTRATOR/RELAY_REVIEWER 覆盖角色。
• 文件：任务/议题文本、可选的 sprint 文件、/tmp/dispatch-<N>.md 和 /tmp/rubric-<N>.yaml。
• 同级脚本：${RELAY_SKILL_ROOT:-skills}/relay/scripts/run-preflight.js、${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js、${RELAY_SKILL_ROOT:-skills}/relay-review/scripts/review-runner.js。

Dev Relay

执行计划 -> 分派 -> 审查周期。GitHub 交付会在 ready_to_merge 阶段停止，除非用户明确要求合并；本地交付会执行规范恢复流程，并在终态 reviewed_result_ready 停止。

角色默认值

• 编排者：除非在分派时设置 RELAY_ORCHESTRATOR，否则为 Codex。
• 执行者：除非分派时通过 --executor 选择其他适配器，否则为 Codex。
• 审查者：除非在分派时设置 RELAY_REVIEWER，否则为 Codex。此绑定不可变；审查时的 --reviewer 必须与其相同，不能用于覆盖。

已分配的 run.json 角色保持不可变；实际审查者数据会单独记录。

第 1 步：来源与重新锚定

在执行任何获取、Forge 查询、工作树、运行目录或执行器操作之前，先对仓库分类。Relay 需要 Git，不会替你运行 git init。首先运行路由预检；它会执行只读来源检查，然后进行特定路由的进行中检查（GitHub 上现有的重复 PR 防护，以及无远程仓库时仅检查本地运行事实）：

PREFLIGHT=$(node "${RELAY_SKILL_ROOT:-skills}/relay/scripts/run-preflight.js" \
  --stage route --repo . --issue-number "$ISSUE_NUMBER" --branch "$BRANCH" --json)

如果 source.route 是 local-reviewed-result，请使用本地任务文本或用户描述，不要运行 git fetch、gh issue view 或任何 PR 查询。运行将继续进行 Git 验证、独立审查以及规范的 Reviewed Result 收尾，不使用 Forge。如果 source.route 是 github，请使用报告中的 source.remote_name 执行现有的重新锚定获取，然后在需要议题文本时使用 gh issue view <N>。此路由保留现有的 GitHub 去重机制，并要求具备经过身份验证的 GitHub 访问权限，以及所选执行者/审查者通常使用的 CLI 身份验证和网络连接。GitLab 和其他 Forge 均不受支持；请配置 GitHub、移除所有远程仓库以进行本地交付，或直接使用 delegate。SOURCE_NOT_GIT 错误会建议显式运行 git init 或直接使用 delegate。

通过此检查后，任务依据所选路由确定：如果 GitHub 路由提供了议题编号，则使用 GitHub 议题文本；否则使用本地任务文本或用户描述。将其中的 track: 或 component: 值用作 sprint 归属标识。如果没有议题编号，请使用描述性分支名称，并在合并时跳过关闭议题的步骤。

Sprint 跟踪为可选项；如需使用，请按 sprint-integration.md 确定归属。

只要 inflight.route != "continue"，就遵循 inflight.instruction；该去重防护具有约束力，路由表见 preflight-guards.md。如果路由为 continue，请根据 ../relay-ready/SKILL.md 中的清单自行判断是否已就绪；没有脚本会对此评分。如果判断结果为 needs_split，请通过先提案的 relay-ready 任务整形流程处理；在任何分派之前，已接受的交接内容将成为 relay-plan 的唯一事实来源。

快速路径：只有在单个就绪叶节点具有稳定的审查锚点，且无需澄清或拆分时，才可跳过 relay-ready。否则请运行 relay-ready；其交接简报将成为下游的唯一事实来源。

第 2 步：计划

始终构建评分标准。 遵循 relay-plan 的流程：阅读任务、恢复完成标准、构建评分标准并生成交接材料。不要从 relay-plan 执行分派；第 3 步负责分派。将分派提示词和评分标准 YAML 写入临时文件，例如 /tmp/dispatch-<N>.md 和 /tmp/rubric-<N>.yaml。

第 3 步：派发（relay-dispatch）

relay 负责生命周期编排；relay-dispatch 负责派发 CLI 语义。使用 --executor 和 --model 显式传入固定的执行器或模型；选择时不会使用目录、预设或模型提示回退。

对于「opencode glm-5.2」这类同时指定执行器和模型的表述，请显式传入这两个值。对于「glm-5.2」这类仅指定模型的表述，不要猜测执行器；请询问执行器相关信息。

node "${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js" . \
  -b issue-<N> --prompt-file /tmp/dispatch-<N>.md --rubric-file /tmp/rubric-<N>.yaml \
  --done-criteria-file <done-criteria-path> --timeout 3600 --detach --json
# To pin dispatch selection, append: --executor <name> --model <provider/model>

如果规范本身就是冻结的完成标准，请省略 --done-criteria-file。--detach 会返回一个 snake_case 启动回执，其中包含 status、run_id、run_dir、worktree、attempt_id、host_handle、dispatcher_pid 和 inspection；尝试日志路径是持久事实。即使调用它的 shell 退出，派发器仍会继续运行。当建议操作为 wait 时，请只读轮询检查结果：

node "${RELAY_SKILL_ROOT:-skills}/relay/scripts/relay-recover.js" inspect --repo . --run-id "$RUN_ID" --json
node "${RELAY_SKILL_ROOT:-skills}/relay/scripts/run-preflight.js" --stage review --repo . --run-id "$RUN_ID" --json

严格遵循 inspection.recommended_action：

• recover → 使用返回的操作键运行规范的 relay-recover recover；只有它会提交、推送并记录或创建准确的 PR。
• review → 继续执行第 4 步。
• redispatch → 使用不可变的 run_id 调用派发；所有其他恢复尝试都会在写入前失败。
• wait → 继续轮询；operator_attention 或 none → 停止并解决阻塞问题。

派发后，对于重复的 wait/recover 轮询，默认使用仅供调用方使用的推进驱动器。它会在每次操作前重新检查，只调用规范恢复，然后打印带类型的停止原因和准确的下一条操作员命令：

node "${RELAY_SKILL_ROOT:-skills}/relay/scripts/relay-advance.js" \
  --run-dir "$RUN_DIR" --json

推进会在需要审查、合并、重新派发、缺少验证证据、需要操作员关注或达到步骤预算时停止；它本身不会派发、审查、合并，也不会获取生命周期锁。如果建议的恢复操作需要不可变验证证据，请提供 --verification-file。

使用 relay-status.js --all 查看离线跨运行控制台。添加 --gc 可进行保留工作树的试运行；仅在明确回收时使用 --apply。

记录 run_id、run_dir 和当前操作键。不可变记录位于 ~/.relay/runs/<repo-slug>/<run-id>/run.json；生命周期状态根据 events.jsonl 和实时观察结果汇总，而不会存储为可变的生命周期状态。对于正在进行的写入，请依照相同的 sprint-integration.md 契约确定所有权。

第 4 步：审查（relay-review）

必须执行。不得跳过此步骤。

审查前先验证。 调用 relay-review 前，请对照保留的工作树核验每项已声明的验证，并说明其结果。只接受实际执行或观察到的结果作为证据。在审查前运行报告为不可用或尚未执行的检查；检查失败或仍不可用时，不得进行审查。

仅当检查结果建议 review 时，才调用 relay-review：

node "${RELAY_SKILL_ROOT:-skills}/relay-review/scripts/review-runner.js" \
  --repo . --run-id "$RUN_ID" --json

在隔离上下文中调用 relay-review。它会记录不可变的审查证据和事实，同时以冻结的完成标准作为审查基准。除非修正后的 HEAD 通过主要审查，否则所请求的更改仍会阻塞后续操作。不得在当前上下文中审查。

运行器会返回 verdict 和新的 recommended_action。在 GitHub 流程中，进入第 5 步前，lgtm 必须建议 merge。在本地流程中，lgtm 必须建议 recover；使用该操作键运行规范恢复，以追加终态 reviewed_result_ready 结果。changes_requested 必须建议 redispatch；通过 dispatch --run-id 发送新提示词，按需执行恢复以发布修正后的 GitHub 版本或保留修正后的本地提交，然后再次审查。运行时调用失败时，可以建议绑定到该失败的一次明确 review 重试；若第二次失败、模型返回 escalated、出现 operator_attention，或操作不匹配，则停止并调查。

第 5 步：完成所选路线

对于 source.route=github，LGTM 必须推导出 merge/ready_to_merge；在用户明确授权 relay-merge 之前，停在此处。对于 source.route=local-reviewed-result，LGTM 必须推导出 recover/reviewed_result_ready；运行该精确恢复操作，并且只有在检查报告终态 Reviewed Result 后才停止。如果在审查过程中发现后续事项，请创建后续问题。

批处理模式

当多个独立任务已准备就绪时，准备一个 relay-fleet 批次，但保留 /relay 的 ready_to_merge 停止状态，直到用户明确授权将其合并；获得授权后，relay-fleet 是默认的并行批处理驱动方式。关于剩余的冲突恢复说明以及“有疑问时，按顺序运行”的原则，请参阅 references/batch-mode.md。

总结检查清单

确认 Done Criteria 已完整实现，具备 relay-review LGTM/审计证据，并且所选路线已达到精确的完成状态：GitHub 为 ready_to_merge，本地交付为终态 reviewed_result_ready。然后按照 sprint-integration.md 应用任何冲刺/后续更新。