> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodus.io/llms.txt
> Use this file to discover all available pages before exploring further.

# コードレビューでリンクリポジトリを使ってクロスレポコンテキストを得る方法

> PRが境界サーフェスに触れるとき、兄弟リポジトリをリンクしてKodyがサービス間のコントラクトやAPIを読めるようにします。

プロダクトが複数のリポジトリに分かれている場合 — たとえばバックエンドAPIを呼ぶフロントエンドや、共有コントラクトパッケージに依存するサービス — 単一リポジトリだけのレビューでは境界での破壊を見逃すことがあります。**リンクリポジトリ**（*linked repositories*）は、コードレビュー中にそれらの兄弟コードベースから任意・オンデマンドのコンテキストをKodyに渡します。

> **プラン要件:** リンクリポジトリは **Teams** および **Enterprise** プランで利用できます（トライアルはプレビューとして含まれます）。Free プランにはクロスレポコンテキストは含まれません。

これは[リポジトリ間でコーディング標準を共有する方法](/knowledge_base/ja/how-to-share-standards-across-repositories)（組織レベルのルールと継承）とは異なります。リンクリポジトリはレビュールールではなく、レビュー用の**ソースコンテキスト**を共有します。

## 何をするか

レビュー対象のリポジトリに対して、同じ組織内で最大**3つ**のリンクリポジトリを宣言します。レビュー中:

1. Kodyは**決定論的な境界ゲート**（LLMなし）でPR diffを見ます。
2. diffが**コントラクトサーフェス**（DTO、export、文字列リテラル、ステータスキー、APIらしいパスなど）に触れているように見える場合、クロスレポツールが有効になります。
3. リンク先は、Kodyが実際に読み取りや検索を必要としたときだけ**遅延クローン**されます。
4. 指摘は引き続き**レビュー中のPRの行にのみアンカー**されます — リンク先のコードは根拠であり、2つ目のレビュー対象ではありません。

リンクが設定されていなければ、機能は完全にオフです（追加コストなし）。

## ダッシュボードでの設定

リンクリポジトリは**リポジトリ単位**であり、グローバルではありません。関係は一方向です: `frontend` 上のリンクは `frontend` のPRをレビューするときだけ適用されます。

1. **コードレビュー設定**を開きます。
2. **特定のリポジトリ**を選択します（Global ではない）。
3. そのリポジトリのメニューから**Linked Repositories**ページを開きます。
4. **Linked repositories** で、組織にすでに接続されている兄弟リポジトリを追加します。
5. 任意で設定:
   * **Instructions** — Kody向けの自由記述のヒント（例: 「このフロントエンドが消費するREST API」）。
   * **Ref** — 任意の branch/tag ピン。空欄のままにすると自動のrefカスケード（下記）を使います。
6. 保存します。

リンクできるのは最大**3**リポジトリです。同じ組織にすでに接続されているリポジトリのみ受け付けます。

## `kodus-config.yml` での設定

リポジトリの設定ファイルでも宣言できます:

```yaml theme={null}
linkedRepositories:
  - repository: "org/backend-api"
    instructions: "REST API this frontend consumes"
    ref: main   # 任意のピン; 省略すると same-branch カスケード
```

* `repository`（必須）: 組織に接続されたリポジトリのフルネーム（`owner/repo`）。
* `instructions`（任意）: リンクの目的の短い説明。
* `ref`（任意）: branch、tag、または commit を固定。省略時はKodyがrefカスケードを使います。

空の `linkedRepositories: []` は機能オフを意味します。

## ref の選び方

各リンクリポジトリについて、Kodyは次の順でrefを試し、最初にクローンに成功したものを使います:

1. そのリポジトリに対する**PR説明のオーバーライド**（下記）
2. **設定の `ref` ピン**（設定されている場合）
3. PRのheadブランチと一致するheadを持つリンク先上の**オープンPR**
4. リンク先上の**PR headブランチ名**
5. リンク先の**デフォルトブランチ**
6. フォールバック: `main`、次に `master`

同じブランチ名がサービス間に存在するマルチレポ作業を揃えつつ、通常のPRでは安全にフォールバックします。

## PR説明からrefを上書きする

一度きりのレビュー（例: 特定のバックエンドPRに対してレビュー）では、レビュー対象PRの**タイトルまたは説明**にリンク済みリポジトリを書いてください。オーバーライドは設定で**すでにリンクされている**リポジトリにのみ適用されます。

対応形式:

| 形式                  | 意味                                       |
| ------------------- | ---------------------------------------- |
| `owner/repo#123`    | そのリポジトリのPR/MR `#123` のheadを使う            |
| PR/MRのURL           | 同上（GitHub、GitLab、Bitbucket、Azure DevOps） |
| `owner/repo@branch` | リンク先でそのブランチを固定                           |

例:

```text theme={null}
Depends on org/backend-api#842
Also needs org/shared-contracts@feature/new-events
```

同じリポジトリへの後の言及が優先されます。**リンクされていない**リポジトリへの言及は無視されます（新しいリンクは作られません）。

## クロスレポコンテキストが有効になるとき（境界ゲート）

リンクが設定されていても、Kodyは**常に**兄弟リポジトリを開くわけではありません。安価で決定論的なゲートがPR diffの**追加行**を走査し、次のような**境界サーフェス**を見つけたときだけ有効になります:

* 文字列リテラル（パス断片、コード、イベント名など）
* export（`export function`、型、クラスなど）
* enum / type / interface
* オブジェクトやペイロードのフィールドキー
* status / state / error-code 風の識別子
* コントラクトらしいパス（`dto`、`schema`、`api`、`client`、`openapi`、`proto` など）

境界サーフェスを触らない内部リファクタでは通常ゲートはオフのまま — クローンと境界プロンプトは起動しません。

## リンクリポジトリでKodyができること・できないこと

**できること:**

* ゲートがオンのとき、リンク先のファイルを検索・読み取り
* **instructions** を使って関係を理解
* 現在のPR上の指摘の根拠としてリンク先コードを引用

**できないこと / しないこと:**

* リンク先にしかないファイルへレビューコメントを投稿
* リンク先リポジトリ全体をPRとしてレビュー
* 組織外、またはKodusに未接続のリポジトリをリンク
* レビュー対象リポジトリあたり3件のソフト上限を超える

## レビュー終了時の透明性

リンクリポジトリが実行に含まれた場合、レビューメタデータは設定されたリポジトリ、解決されたref（およびソース: 説明、ピン、オープンPR、headブランチ、またはdefault）、境界ゲートが有効だったかを記録します。失敗やスキップされたリンクは警告として表面化し、レビュー全体は失敗しません。

## 推奨セットアップ

| シナリオ               | リンク元                     | 典型的な instructions          |
| ------------------ | ------------------------ | -------------------------- |
| Frontend ↔ backend | Frontend → APIリポジトリ      | 「このUIが依存するHTTP/RESTコントラクト」 |
| サービス ↔ 共有コントラクト    | サービス → contracts/package | 「共有イベント、DTO、protobuf」      |
| BFF ↔ 複数バックエンド     | BFF → 最大3つのbackend       | サービス境界ごとに短い1行              |

すべてのリポジトリを相互にリンクするより、**狭く一方向**のリンク（消費者が生産者を指す）を推奨します。

## 関連ガイド

* [リポジトリ間でコーディング標準を共有する方法](/knowledge_base/ja/how-to-share-standards-across-repositories) — 組織レベルのルールと継承（ソースコンテキストではない）
* [プロジェクト固有のコンテキストでPRをレビューする方法](/knowledge_base/ja/how-to-review-prs-with-project-context) — メモリ、ファイル参照、カスタムプロンプト、MCP
* [コードレビューのノイズを減らす方法](/knowledge_base/ja/how-to-reduce-code-review-noise) — コンテキストを増やしてもレビューを焦点に保つ