relay

入力

• 環境変数：任意の RELAY_SKILL_ROOT のデフォルトは skills です。ロールの上書きには RELAY_ORCHESTRATOR／RELAY_REVIEWER を使用します。
• ファイル：タスク／Issue のテキスト、任意のスプリントファイル、/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

plan -> dispatch -> review のサイクルを実行します。GitHub へのデリバリーは、ユーザーが明示的にマージを求めない限り ready_to_merge で停止します。ローカルでのデリバリーでは、標準の復旧処理を実行し、終端状態の reviewed_result_ready で停止します。

ロールのデフォルト

• オーケストレーター：ディスパッチ時に RELAY_ORCHESTRATOR が設定されていない場合は Codex です。
• 実行担当：ディスパッチの --executor で別のアダプターが選択されていない場合は Codex です。
• レビュアー：ディスパッチ時に RELAY_REVIEWER が設定されていない場合は Codex です。この割り当ては 変更できません。レビュー時の --reviewer はこの設定と一致する必要があり、上書きには使えません。

割り当てられた run.json のロールは変更できません。実際にレビューを行ったレビュアーの情報は別途記録されます。

Step 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 の検索を実行しないでください。Forge を使わずに、Git の検証、独立したレビュー、標準の Reviewed Result クローズ処理を行います。source.route が github の場合は、既存の再基点設定用フェッチに報告された source.remote_name を使用し、Issue のテキストが必要な場合は gh issue view <N> を使用します。このルートでは現在の GitHub の重複排除が適用され、認証済みの GitHub アクセスに加え、選択した実行担当／レビュアーの通常の CLI 認証情報とネットワーク接続が必要です。GitLab やその他の Forge はサポートされていません。GitHub を設定するか、ローカルでデリバリーする場合はすべてのリモートを削除するか、直接 delegate を使用してください。SOURCE_NOT_GIT エラーが発生した場合は、明示的な git init または直接の delegate が推奨されます。

タスクの根拠情報は、このゲートの後で選択したルートに従います。GitHub ルートで Issue 番号がある場合は GitHub の Issue テキストを、それ以外の場合はローカルのタスクテキストまたはユーザーの説明を使用します。スプリントの担当先を示す値として、その中の track: または component: を使用してください。Issue 番号がない場合は、内容を表すブランチ名を使用し、マージ時の Issue クローズ処理を省略します。

スプリントの追跡は任意です。使用する場合は、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 を実行してください。その引き継ぎ用ブリーフが、後続処理の唯一の信頼できる情報源になります。

Step 2: 計画

必ずルーブリックを作成してください。 relay-plan の手順に従い、タスクを読み、完了条件を確認し、ルーブリックを作成して、引き継ぎ用の成果物を出力します。relay-plan からディスパッチを実行してはいけません。ディスパッチは Step 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 は、status、run_id、run_dir、worktree、attempt_id、host_handle、dispatcher_pid、inspection を含む snake_case の起動レシートを返します。試行ログのパスは永続的な事実です。呼び出し元のシェルが終了しても、ディスパッチャーは処理を続けます。推奨アクションが 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 のポーリングを繰り返す際のデフォルトのコンベヤーには、呼び出し元専用の advance ドライバーを使用します。ドライバーは各アクションの前に再インスペクションを行い、正規のリカバリーのみを呼び出してから、型付きの停止理由と正確な次のオペレーターコマンドを出力します。

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

Advance は、レビュー、マージ、再ディスパッチ、検証エビデンスの欠落、オペレーター対応、またはステップ予算のいずれかに達すると停止します。自身でディスパッチ、レビュー、マージ、またはライフサイクルロックの取得を行うことはありません。推奨されたリカバリーで不変の検証エビデンスが必要な場合は、--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 の再試行が 1 回だけ推奨される場合があります。2 回目の失敗、モデルが返す 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 が報告された後にのみ停止する必要があります。レビュー中に見つかった場合は、フォローアップの issue を作成してください。

バッチモード

複数の独立したタスクを実行できる状態になったら、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 に従って、スプリントやフォローアップの更新を適用してください。