relay-plan

入力

• 環境：省略可能な RELAY_SKILL_ROOT のデフォルト値は skills です。
• ファイル：relay-ready の引き継ぎ資料、issue／ユーザーのテキスト、省略可能なローカルタスクのテキスト、省略可能なローカルハーネスのコンテキスト（AGENTS.md、CLAUDE.md、CHARTER.md、spec/capabilities.md、進行中のスプリントノート）、省略可能な /tmp/done-criteria-<N>.md、/tmp/dispatch-<N>.md、および互換性のために名前を付けた評価成果物 /tmp/rubric-<N>.yaml。
• 関連スクリプト：${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/probe-executor-env.js、${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/persist-done-criteria.js、${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js。

Relay Plan

使用する場合

• relay の実行に向けて、レビューの基準点、構造化された評価チャネル、ディスパッチ用プロンプトを作成する場合
• タスクの意図、明示的な AC、リポジトリのシグナル、リスクを、レビュー可能な Done Criteria に変換する場合
• ディスパッチ前に、プランナーが作成した Done Criteria を保存する場合

使用しない場合

• 計画前に曖昧なタスクを整理する場合 — relay-ready を使用します
• 実装をエグゼキューターに委任する場合 — relay-dispatch を使用します
• エグゼキューターの出力をレビューする場合 — relay-review を使用します
• レビュー済みの GitHub 変更を取り込む場合 — relay-merge を使用します

relay-plan は引き継ぎ成果物のみを出力します。relay-dispatch は relay またはオペレーターが実行します。

デフォルトの手順

1. タスクを読む

タスクの根拠を読む前に、/relay のソースゲートで選択された経路を使用します。リモートのない Git チェックアウトはローカルの Reviewed Result の受け渡しであり、ローカルのタスクテキストまたはユーザーの説明を使い、forge の検索は行いません。サポートされている GitHub 経路では、ソースゲートを通過した後に gh を使って issue のテキストを取得できます。

選択した経路に応じて、正規化されたタスクソースを読みます。

• relay-ready の引き継ぎ概要がある場合：~/.relay/requests/<repo-slug>/<request-id>/relay-ready/<leaf-id>.md
• issue 番号がある GitHub 経路：ソースゲートの通過後に gh issue view <N> を実行します。この取得に失敗した場合は処理を続行しません。ローカルテキストにフォールバックしないでください。
• issue 番号のない GitHub 経路、またはローカル経路：ローカルのタスクテキストまたはユーザーが提供した説明。ローカル経路では forge を検索してはいけません。

relay-ready が引き継ぎ概要を生成している場合は、元の依頼を読み直すのではなく、その概要を信頼できる情報源として扱います。 整理済みのリーフでは、保存済みの relay-ready/<leaf-id>.md と、固定された Done Criteria のパスを使用します。元の依頼は過去のコンテキストにすぎず、別のタスクとして暗黙に再解釈してはいけません。 relay-ready の基準点が不完全な場合は、曖昧さを明らかにするか、ステップ 7 でプランナーが作成した Done Criteria を保存します。

2. 計画シグナルを収集する

node "${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/probe-executor-env.js" . --project-only --json

リポジトリ内の品質シグナルと、タスクに関連するローカルハーネスのコンテキストは、弱い入力としてのみ読み取ります。これらは表現、前提条件、コマンド、調査箇所の判断材料になりますが、ディスパッチを妨げたりタスクに優先したりするものではありません。各項目の意味と権限の優先順位については、references/signals.md を参照してください。

3. 計画入力を正規化する

レビューの基準点を作成するまでは、明示的な AC、推定した Done Criteria、relay-ready の引き継ぎ資料、プロジェクトのハーネスコンテキスト、リポジトリシグナル、省略可能なサブシステム調査メモ、タスクのリスクを、それぞれ独立した根拠チャネルとして扱います。

4. Done Criteria を導き出す

評価の情報源モデルを特定します。

• タスクソースに明示的な AC がある場合は、その AC
• ユーザーの意図、issue の本文、relay-ready の引き継ぎ資料、近隣のリポジトリ規約から推定した Done Criteria
• プローブ、利用可能なコマンド、タスクに関連する規約から得られるリポジトリシグナル
• 変更対象の領域、信頼境界、データ損失、移行、UX フロー、運用上の障害モードに基づくタスク固有のリスク

AC がない、曖昧、または不完全な場合は、まず観測可能な Done Criteria を作成します。明示的な AC は優先度の高い根拠として扱いますが、唯一の情報源にはしません。確定する前に、曖昧さの事前監査を実行します。最終的なレビューの基準点をプランナーが作成した場合、またはタスクソースと異なる場合は、ステップ 7 で保存します。

5. 評価チャネルを構築する

references/evaluation-channels.md に従い、Outcome Contract、Verification、任意の Earned Rubric を分けてください。固定された Done Criteria が契約となります。最小限の成果物：

evaluation:
  schema_version: 2
  outcome_contract:
    source: done_criteria
  verification:
    checks:
      - name: Focused behavior passes
        type: command
        command: "<task-specific command>"
        target: "<observable pass condition>"
  earned_rubric:
    factors: []

テスト、ビルド、型チェック、Lint、成果物の存在確認などの二値の証拠は、Verification に含めます。Earned Rubric の要素がゼロでも問題ありません。Gradient、Observable、Actionable、Consequential のすべてを満たした場合にのみ、要素が獲得されます。任意の数値へのマッピングを行う前に、質的な弱・適切・強の基準を使用してください。詳細は references/evaluation-channels.md を参照してください。 品質を導き出す前に観察します。成果物、想定されるユーザー、利用状況、利用可能な対象を特定してから、references/observation-lenses.md の任意の質問を使用してください。

6. チャネルを検証して簡素化する

引き渡し前の簡易チェック：Outcome Contract の項目は二値で観察可能であること、Verification のチェックでは具体的な証拠を明記すること、Earned Rubric は空でもよく、日常的な衛生項目を含めないこと。完全なチェックリストは references/rubric-validation.md を参照してください。

保存する前に、references/rubric-simplification.md を適用します。HOW を観察可能な WHAT に書き換え、重複を統合し、根拠のない防御的な条項を削除して、重みを確認してください。

7. 必要に応じてプランナー作成の Done Criteria を保存する

最終的な Done Criteria をプランニングで作成する場合、または issue の本文にある AC を拡張、却下、もしくは範囲縮小する場合にのみ保存します。これには、AC がない入力、ユーザー提供の説明、プランニングによって issue の本文にある AC が変更されるすべてのケースが含まれます。

最終バイト列を、親ディレクトリがすでに存在し、シンボリックリンクではない明示的なパスに出力します。この手順では実行 ID を割り当てず、~/.relay/runs 配下への出力は拒否します。ディスパッチによって実行が作成され、その後にこのバイト列が固定されます。

node "${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/persist-done-criteria.js" \
  --output /tmp/done-criteria-<N>.md --file /tmp/done-criteria-source-<N>.md --json

issue または relay-ready の引き渡しに、プランナーによる変更なしで最終的な Done Criteria がすでに含まれている場合は、この手順を省略してください。

8. 引き渡し成果物を出力する

ディスパッチプロンプトと評価 YAML を一時ファイルに書き込みます。プロンプトでは ../relay/references/prompt-template.md を使用し、Setup、任意の Working Guidance、Evaluation Channels、Completion Responsibilities を追加します。評価成果物は、互換性のための名前である --rubric-file を介して渡します。references/iteration-protocol.md では、簡潔な証拠と引き渡しの契約、および任意の TDD 形式を定義しています。

すべての実行者に同じプロンプトテンプレートと完了責任を使用します。実行者のアダプターは実際の呼び出しツールを保持します。プロンプトの内容によって、異なる Outcome Contract や Verification の契約が選択されることはありません。

ディスパッチプロンプトのパス、rubric YAML のパス、保存した場合は Done Criteria のアンカーパス、および推奨する relay-dispatch コマンドを含む引き渡し概要を返します。

ステップ 7 で Done Criteria を保存した場合、ディスパッチ時の引き渡しでは両方のアンカーを保持する必要があります。

node "${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js" . \
  --branch issue-<N>-<slug> --prompt-file /tmp/dispatch-<N>.md --rubric-file /tmp/rubric-<N>.yaml \
  --done-criteria-file <done-criteria-path>

relay-plan から relay-dispatch を実行しないでください。

リスクに応じた追加項目

タスクの根拠が必要性を示す場合に限って追加項目を使用してください。参照チェックリストをプロンプトにそのままコピーしないでください。

• ルーブリックのテンプレート用ひな形：references/rubric-templates/_index.json を読み、Step 2 の調査出力と signals（test_infra、type_check、lint_format）が重なるテンプレートを選びます。重なりがなければ、タスクに基づいてルーブリックを作成します。テンプレートは手作業で調整するための出発点であり、自動適用されるものでも、契約そのものでもありません。
• TDD を取り入れた要素：その要素において、レッドファーストテストが適している場合（明確な動作、特定のパスが 1 つ、対象を指定できるランナーがある場合）に限り、要素に tdd_anchor: <test path>（任意で tdd_runner）を付与します。Step 2 の調査で使用可能なテストランナーが報告され、自動化された契約要素にまだアンカーがない場合は、追加を提案します。ドキュメント、文章、UI の判断、広範な設計に関する要素にはアンカーを付けません。解決可能なランナーのない tdd_anchor 要素がある場合、Step 0a の前にフェイルクローズします：references/iteration-protocol.md。
• task_profile または作業ガイダンス：references/task-profile.md と references/guidance-packs.md。
• ドメイン別のルーブリック案：references/rubric-domain-axes.md。
• 観察優先のドメイン別質問：references/observation-lenses.md。
• 信頼境界とフェイルクローズ動作：references/rubric-trust-model.md と references/rubric-fail-closed-patterns.md。
• ファイル／パスの精度、禁止領域、イベント形式の変更、または TDD を取り入れた要素：references/rubric-patterns.md。
• L/XL の曖昧さ、またはサブシステムの境界が不明確な場合：references/subsystem-scout.md を使った読み取り専用の調査を検討します。スコープが明確な S/M タスクでは省略します。
• 新規性が高い、曖昧、リスクが高い、または簡単に攻略できる完了基準の場合：references/rubric-stress-test.md を使ってストレステストを 1 回実施します。サイズを問わず、曖昧さやリスクがあればストレステストを選択できます。
• レビューのフィードバック後に再ディスパッチする場合：元のアンカーを固定し、前回の試行に関する根拠とレビュアーのフィードバックを自動的に先頭に追加します。移行中は従来の Score Log のテキストも引き続き読み取り可能ですが、実行者が記入したスコアはレビューの根拠にはなりません。