Back to Details

release-train-runner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

用途

Merge N reviewed PRs into a single release branch on remote compute (Ona or Codespaces), one PR at a time, in order. Run the full test suite after each merge. Produce one release PR with conflicts documented and a unified manual test plan, plus a local report.
This skill runs in the OPERATOR session and owns its worker lifecycle. It spawns a repo worker devbox via the gateway worker API (see 
pylot-workers
skill) and drives stages 01-06 through the worker. Stage 00 (claim compute) and stage 07 (report + outcome marker) run inline in the operator.
This procedure is FULLY SEQUENTIAL. There is no parallelism anywhere. Each PR generates new conflicts for every other PR, so PRs MUST be validated and integrated ONE AT A TIME, in the provided order, inside a single loop in stage 03. Do NOT fan out per-PR subagents.
将N个已审核的PR按顺序逐个合并到远程计算环境（Ona或Codespaces）中的单个发布分支，每次合并后运行完整测试套件。生成一个记录冲突情况并包含统一手动测试计划的发布PR，同时生成一份本地报告。
此Skill在OPERATOR会话中运行并管理其worker生命周期。它通过网关worker API（参见
pylot-workers
Skill）生成一个repo worker开发环境，并通过worker驱动01-06阶段。00阶段（申请计算资源）和07阶段（报告+结果标记）在operator中内联运行。
此流程是完全串行的，不存在任何并行操作。每个PR都会给其他所有PR带来新的冲突，因此必须按照提供的顺序逐个验证和集成PR，在03阶段的单个循环内完成。请勿为每个PR单独生成子代理。

Worker Setup

Worker设置

Spawn a worker at stage 00 (after claiming compute) for stages 01-06:
bash
REPO="${0:-$PYLOT_REPO}"
SPAWN_RESP=$(curl -s --max-time 90 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"repo\": \"$REPO\"}" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers")
WID=$(echo "$SPAWN_RESP" | python3 -c 'import sys,json; print(json.load(sys.stdin).get("worker_id",""))' 2>/dev/null)
Drive each stage as a separate prompt using the 
pylot-workers
drive loop pattern. Poll to idle between stages. Stop the worker after stage 06 completes, before the inline stage 07 writes the report and emits the outcome marker:
bash
curl -s --max-time 30 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers/${WID}/stop" >/dev/null 2>&1 || true
在00阶段（申请计算资源后）为01-06阶段生成一个worker：
bash
REPO="${0:-$PYLOT_REPO}"
SPAWN_RESP=$(curl -s --max-time 90 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"repo\": \"$REPO\"}" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers")
WID=$(echo "$SPAWN_RESP" | python3 -c 'import sys,json; print(json.load(sys.stdin).get("worker_id",""))' 2>/dev/null)
使用
pylot-workers
驱动循环模式，将每个阶段作为单独的提示来驱动。在阶段之间轮询直到空闲。在06阶段完成后、内联阶段07写入报告并发出结果标记之前，停止worker：
bash
curl -s --max-time 30 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers/${WID}/stop" >/dev/null 2>&1 || true

Arguments

参数

ParamRequiredDefaultNotes
repo
yes—
org/repo
, e.g. 
Lexgo-cl/rails-backend
(parsed as 
$0
)
pr_numbers
yes—Space-separated PR numbers in merge order, e.g. 
1372 1375 1430
(
$1 $2 $3 ...
)
instructions
no—Complementary guidance in trailing parentheses; narrows scope
Parse from 
$ARGUMENTS
: first token is the repo, remaining bare integers are PR numbers in order, trailing 
(...)
is optional complementary instructions. Merge order = the order provided.
参数必填默认值说明
repo
是—
org/repo
格式，例如
Lexgo-cl/rails-backend
（解析为
$0
）
pr_numbers
是—按合并顺序排列的空格分隔PR编号，例如
1372 1375 1430
（
$1 $2 $3 ...
）
instructions
否—括号中的补充指导；缩小范围
从
$ARGUMENTS
解析：第一个令牌是repo，其余整数是按顺序排列的PR编号，末尾的
(...)
是可选的补充说明。合并顺序=提供的顺序。

What it does

功能说明

8-stage FULLY SEQUENTIAL ICM procedure:
StageModeDescription
00-claim-computeinlineClaim remote env (Ona or Codespaces); set 
REMOTE_EXEC
+ 
REPO_DIR
01-preflightsubagentDefault branch, PR manifest, validate PRs, clean the env
02-release-branchsubagentCut 
release/YYYY-MM-DD
from default branch
03-validate-integratesubagentSequential in-order loop: per PR → validate → merge → resolve conflicts → test → log; next PR
04-lockfilessubagentRegenerate lockfiles if any merged PR touched deps; re-test
05-push-release-prsubagentPush release branch; open one release PR with unified test plan
06-release-envsubagentWrite async trigger notification; release/stop remote compute
07-reportinlineWrite local report file; emit outcome marker
Stage 03 is the isolated critical-judgement stage: PR validation, conflict resolution, and merge verdicts all happen there in one clean context, looping over PRs sequentially.
8个阶段的完全串行ICM流程：
阶段模式描述
00-claim-compute内联申请远程环境（Ona或Codespaces）；设置
REMOTE_EXEC
和
REPO_DIR
01-preflight子代理默认分支、PR清单、验证PR、清理环境
02-release-branch子代理从默认分支创建
release/YYYY-MM-DD
分支
03-validate-integrate子代理按顺序串行循环：每个PR → 验证 → 合并 → 解决冲突 → 测试 → 记录；处理下一个PR
04-lockfiles子代理如果任何合并的PR修改了依赖项，则重新生成锁文件；重新测试
05-push-release-pr子代理推送发布分支；创建一个包含统一测试计划的发布PR
06-release-env子代理写入异步触发通知；释放/停止远程计算资源
07-report内联写入本地报告文件；发出结果标记
03阶段是关键判断阶段：PR验证、冲突解决和合并结论都在一个干净的上下文中进行，按顺序循环处理PR。

Handoff locations

交接位置

All handoffs live in the repo working directory:
.procedure-output/release-train-runner/{stage}/handoff.md
Stage 00 writes the compute-claim context. Each subagent stage receives only the handoffs its CONTEXT.md lists as inputs — never the full orchestrator context.
所有交接文件都位于repo工作目录中：
.procedure-output/release-train-runner/{stage}/handoff.md
00阶段写入计算资源申请上下文。每个子代理阶段仅接收其CONTEXT.md中列为输入的交接文件——绝不接收完整的编排器上下文。

Execution

执行流程

Stage 00 (inline)

00阶段（内联）

Run stage 00 yourself (orchestrator context). Read CONTEXT.md:
.claude/skills/release-train-runner/stages/00-claim-compute/CONTEXT.md
Claim the remote environment, resolve 
REMOTE_EXEC
and 
REPO_DIR
, and write handoff to 
.procedure-output/release-train-runner/00-claim-compute/handoff.md
.
自行运行00阶段（编排器上下文）。阅读CONTEXT.md：
.claude/skills/release-train-runner/stages/00-claim-compute/CONTEXT.md
申请远程环境，解析
REMOTE_EXEC
和
REPO_DIR
，并将交接内容写入
.procedure-output/release-train-runner/00-claim-compute/handoff.md
。

Stages 01 → 06 (sequential subagents — one at a time)

01 → 06阶段（串行子代理——逐个执行）

For each stage in order, spawn exactly ONE Task. Wait for it to finish before launching the next. Never launch two stages in the same response. There are no parallel stages.
Each Task prompt must be self-contained:
  • Include only the input handoff paths the stage's CONTEXT.md lists
  • Include the path to the stage's CONTEXT.md
  • Do NOT pass orchestrator history or prior reasoning
Task prompt template:
You are running stage {NN}-{name} of the release-train-runner procedure.

Read your stage instructions:
  .claude/skills/release-train-runner/stages/{NN}-{name}/CONTEXT.md

Your inputs:
  .procedure-output/release-train-runner/{prior-stage}/handoff.md
  (...any other handoffs the CONTEXT.md lists)

Write your output to:
  .procedure-output/release-train-runner/{NN}-{name}/handoff.md

Execute all steps in CONTEXT.md. Write handoff.md before exiting.
If any stage emits a hard blocker (e.g. no compute in 00, zero valid PRs in 01), emit the matching outcome marker and stop. A single skipped PR in stage 03 does NOT stop the chain.
按顺序处理每个阶段，每个阶段生成恰好一个Task。等待当前阶段完成后再启动下一个。绝不在同一响应中启动两个阶段。不存在并行阶段。
每个Task提示必须是自包含的：
  • 仅包含阶段的CONTEXT.md中列出的输入交接路径
  • 包含阶段的CONTEXT.md路径
  • 请勿传递编排器历史或先前的推理内容
Task提示模板：
You are running stage {NN}-{name} of the release-train-runner procedure.

Read your stage instructions:
  .claude/skills/release-train-runner/stages/{NN}-{name}/CONTEXT.md

Your inputs:
  .procedure-output/release-train-runner/{prior-stage}/handoff.md
  (...any other handoffs the CONTEXT.md lists)

Write your output to:
  .procedure-output/release-train-runner/{NN}-{name}/handoff.md

Execute all steps in CONTEXT.md. Write handoff.md before exiting.
如果任何阶段发出硬阻塞（例如00阶段没有可用计算资源、01阶段没有有效的PR），则发出匹配的结果标记并停止。03阶段中单个PR被跳过不会终止整个流程。

Stage 07 (inline)

07阶段（内联）

Run stage 07 yourself (orchestrator context). Read CONTEXT.md:
.claude/skills/release-train-runner/stages/07-report/CONTEXT.md
Write the local report file, then emit the 
[pylot] outcome=...
marker from the orchestrator (never from a subagent).
自行运行07阶段（编排器上下文）。阅读CONTEXT.md：
.claude/skills/release-train-runner/stages/07-report/CONTEXT.md
写入本地报告文件，然后从编排器（而非子代理）发出
[pylot] outcome=...
标记。

Stage handoff chain

阶段交接链

00 ─► 01 ─► 02 ─► 03 ─► 04 ─► 05 ─► 06 ─► 07 (inline, reads all)
              (per-PR loop:
               validate → merge → resolve → test,
               one PR at a time, in order)
00 ─► 01 ─► 02 ─► 03 ─► 04 ─► 05 ─► 06 ─► 07 (内联，读取所有内容)
              (每个PR循环：
               验证 → 合并 → 解决冲突 → 测试，
               按顺序逐个处理PR)

Exit paths

退出路径

  • Success: stage 07 emits 
    [pylot] outcome="release train ready: N PRs merged into release/YYYY-MM-DD" status=success
  • Failure: failing stage emits 
    [pylot] outcome="release-train failed at stage NN: {reason}" status=failed
  • Blocked: no compute claimable (00) or no valid PRs to merge (01) → 
    [pylot] outcome="release-train blocked: {reason}" status=blocked
The outcome marker is always emitted by the orchestrator (inline), never by a subagent.
  • 成功：07阶段发出 
    [pylot] outcome="release train ready: N PRs merged into release/YYYY-MM-DD" status=success
  • 失败：失败阶段发出 
    [pylot] outcome="release-train failed at stage NN: {reason}" status=failed
  • 阻塞：无法申请计算资源（00阶段）或没有可合并的有效PR（01阶段）→ 
    [pylot] outcome="release-train blocked: {reason}" status=blocked
结果标记始终由编排器（内联）发出，而非子代理。

Hard Rules

硬性规则

  1. FULLY SEQUENTIAL — no parallelism. Never launch two Task calls in one response. There are no parallel stages.
  2. Per-PR validate+integrate is sequential and in-order. Stage 03 loops over PRs one at a time in the provided order. NEVER fan out per-PR subagents — each merge changes the conflict surface for every later PR.
  3. A PR is reviewed in cohesion — the whole diff, all dimensions together. Never split a PR review across files or dimensions.
  4. Stage 00 runs inline — compute is claimed in orchestrator context so 
    REMOTE_EXEC
    / 
    REPO_DIR
    are stable for downstream stages.
  5. Stage 07 runs inline — 
    [pylot] outcome=...
    marker MUST come from the orchestrator.
  6. Never pass full orchestrator context into subagent Task prompts — inputs only.
  7. Each stage writes handoff.md before the next stage reads it.
  8. Do not skip stages — every stage executes even if its action is "nothing to do" (e.g. stage 04 with no dependency changes still runs and records "no lockfile changes").
  9. Skip rather than break. A PR that fails validation, conflicts irreconcilably, or breaks tests is skipped/reverted and logged — it does NOT abort the train.
  10. Never merge the release PR, never force-push, always 
    --no-ff
    , always test after each merge.     Max reviews and merges the release PR manually.
  11. NO QUEST. Reporting is the local report file only (stage 07) plus the async trigger notification (stage 06). No Quest POST, no Quest token, no Quest URL anywhere.
  1. 完全串行——无并行操作。绝不在同一响应中启动两个Task调用。不存在并行阶段。
  2. 每个PR的验证+集成是串行且按顺序的。03阶段按提供的顺序逐个循环处理PR。请勿为每个PR单独生成子代理——每次合并都会改变后续所有PR的冲突面。
  3. PR审核是整体性的——审查完整差异和所有维度。请勿将PR审核拆分为不同文件或维度。
  4. 00阶段内联运行——在编排器上下文中申请计算资源，以便
    REMOTE_EXEC
    /
    REPO_DIR
    对下游阶段保持稳定。
  5. 07阶段内联运行——
    [pylot] outcome=...
    标记必须来自编排器。
  6. 绝不将完整编排器上下文传递给子代理Task提示——仅传递输入。
  7. 每个阶段在写入handoff.md后，下一阶段才能读取它。
  8. 请勿跳过阶段——即使某个阶段的操作是“无操作”（例如04阶段没有依赖项变更，仍需运行并记录“无锁文件变更”），每个阶段都必须执行。
  9. 跳过而非中断。验证失败、冲突无法调和或导致测试失败的PR会被跳过/回滚并记录——不会终止整个流程。
  10. 绝不合并发布PR，绝不强制推送，始终使用
    --no-ff
    ，每次合并后始终测试    。发布PR需手动进行最大程度的审核和合并。
  11. 禁止使用QUEST。仅通过本地报告文件（07阶段）和异步触发通知（06阶段）进行报告。任何地方都不允许使用Quest POST、Quest令牌或Quest URL。

Reference files

参考文件

  • CONTEXT.md
    — architecture overview
  • shared/release-pr-template.md
    — release PR body template (used by stage 05)
  • shared/report-template.md
    — local report template (used by stage 07)
  • shared/test-commands.md
    — per-project test command lookup (used by stages 03 and 04)
  • stages/NN-name/CONTEXT.md
    — per-stage inputs, task, output contract
  • CONTEXT.md
    — 架构概述
  • shared/release-pr-template.md
    — 发布PR正文模板（05阶段使用）
  • shared/report-template.md
    — 本地报告模板（07阶段使用）
  • shared/test-commands.md
    — 每个项目的测试命令查询（03和04阶段使用）
  • stages/NN-name/CONTEXT.md
    — 每个阶段的输入、任务、输出约定