Skip to main content
リンクされたリポジトリを使うと、プルリクエストのレビュー中に Kody が兄弟リポジトリを読み取り専用のコンテキストとして参照できます。単一リポジトリのレビューでは見えないバグを捕まえるための機能です。たとえば、バックエンドが API のフィールド名を変えたのにフロントエンドが古い名前を読み続けている、producer が追加した enum の値をどの consumer も処理していない、writer と reader が同じキーを別々の方法で導出している、といったケースです。 Teams および Enterprise プランで利用できます。設定はリポジトリ単位です。グローバルなデフォルトはありません。関係は方向性を持つためです。frontend → backend-api をリンクすると、frontend のレビューが backend-api を参照できるようになりますが、その逆にはなりません。両チームがチェックを望むなら、両方向を明示的にリンクしてください。

​
何が得られるか

具体例を挙げます。フロントエンドの PR が次のエラーハンドリングを追加したとします：
バックエンドをリンクしておくと、Kody は契約の反対側を確認し、PR にこうコメントします：
Bug · medium — フロントエンドは error.response?.data?.error が INTEGRATION_NOT_APPROVED かを見ていますが、バックエンドの sendError はコードを message フィールドで返します。not-approved の分岐は決して一致せず、ユーザーには常に汎用のエラートーストが表示されます。代わりに data.message を読んでください。
レビューのサマリーには参照先も表示されます：Additional context used: org/backend-api@main。

​
仕組み

リンクされたリポジトリを持つリポジトリのプルリクエストが境界面（変更された文字列リテラル、ペイロードのフィールド、ステータス値、エクスポートされたシンボル）に触れると、Kody のレビューエージェントは自分のリポジトリを grep するのと同じ要領で、リンクされたリポジトリを検索・読み取り、契約の両側が今も一致しているかを検証できます。指摘は相手側ファイルの確証が取れた場合にのみ挙げられ、コメントは常にあなたの PR の行に付きます。リンク先のコードはその中で裏付けとして引用されるだけで、直接コメントされることはありません。 リポジトリ横断のコンテキストを使ったレビューはその旨を示します。サマリーに Additional context used の行が入り、各リポジトリと読み取った ref が列挙されます。
  • リンクできるのは同じ Kodus 組織にすでに接続されているリポジトリだけです（Kody は既存の Git 連携を再利用します — 追加のトークンは不要）。
  • 1 リポジトリあたり最大 3 つのリンク先。
  • アクセスは読み取り専用です。Kody がリンク先リポジトリに push・コメント・変更を行うことはありません。
  • リンク先リポジトリを取得できない場合（権限、タイムアウト）、レビューはそれなしで通常どおり続行します。

​
リンク先リポジトリの追加

Code Review Settings → 対象リポジトリ → Linked Repositories を開き、一覧からリポジトリを選んで（接続済みのものだけが表示されます）保存します。各リンクには任意の項目が 2 つあります（下記）。

​
Instructions（指示）

このリンクが何のためのもので、どこを見ればよいかをレビューエージェントに伝える自由記述のヒントです。なくても Kody は動きますが、良い指示があるとリポジトリ横断のパスが速く正確になります。エージェントがリンク先をゼロから探索するか、関連コードに直行するかの差です。 良い指示は、関係と要となるパスを名指しします：
弱い指示は自明なこと（「バックエンドのリポジトリ」）を繰り返すだけで、何も足しません。

​
Ref pin（ブランチの選択）

Kody がリンク先リポジトリのどのブランチ（“ref”）を読むかを制御します。多くのチームは空のままにします。その場合 Kody は、自分の PR のブランチと同名のブランチが存在すればそれを読み（マージ前に複数リポジトリの協調変更が互いを見えるように）、なければデフォルトブランチにフォールバックします。 解決順序は次のとおりで、最初に一致したものが採用されます：
  1. PR 説明文での上書き — レビュー対象 PR の説明に、リンク先のブランチや PR を書きます（例：org/backend-api#123 や org/backend-api@feature-x）。単発かつ最優先。すでにリンク済みのリポジトリにのみ適用されます。
  2. 設定の ref ピン（この項目）が設定されていれば。
  3. 一致するブランチのオープン PR — リンク先リポジトリで、head ブランチが自分の PR の head ブランチと一致するオープンなプルリクエスト。
  4. リンク先リポジトリの同名ブランチ。
  5. リンク先リポジトリのデフォルトブランチ（次いで main/master にフォールバック）。
複数リポジトリにまたがる機能開発の足並みを揃えるのが 3〜4 です。まだ変更を含まないデフォルトブランチではなく、マージ前の対になる変更をレビューが見られます。 ref ピン（例：main、develop、release/2.x）は、安定ブランチに対して決定的なレビューを行いたいときに設定します。たとえば、無関係な作業でリポジトリ間にブランチ名が使い回されていて、同名一致が誤ったものを拾ってしまう場合です。単発のケースでは PR 説明文での上書きがピンより優先されます。 レビューのサマリーには、実際に使われた ref が常に表示されます。例つきの手順は リンクされたリポジトリの使い方 を参照してください。

​
使いどころ

リンクされたリポジトリが効くのは、ツールでは強制されない契約をリポジトリ同士が共有している場合です：
  • 各側でペイロードの形を再宣言している フロントエンド ↔ バックエンド のペア。
  • ステータス値・イベント名・ID をやり取りする サービス ↔ サービス 連携。
  • 共有ライブラリの型を再実装・ミラーしている 共有ライブラリの利用側。
リンクされたリポジトリは、コードの外にある契約はカバーしません。たとえばサードパーティ API のバリデーション規則は、どのリンク先リポジトリからも見つけられません。