change-review

Repowise による変更レビュー

差分が提示されたら、Repowise は「どのファイルが変更されたか」を「この変更は何を危険にさらすか」へと変換します。git の履歴（変更頻度、所有者、同時変更）とグラフのトポロジー（依存先、影響範囲）、テストの不足、セキュリティシグナル、変更対象コードを規定するアーキテクチャ上の決定を融合します。

相互に補完する2つのリスクシグナルがあるため、両方を使ってください。

• get_change_risk(revspec=…)（MCP） は、変更全体を1つの単位として（コミットまたは base..head の範囲）スコアリングします。LLM もネットワークも不要です。revspec を受け取り、サーバー側で差分を取得するこの MCP 内のツールを優先してください。シェルコマンドを実行する必要はありません。まず directive と health_delta を確認します。つまり、この変更によって実際に悪化した点です。この変更で発生した検出結果は、変更によって触れられただけの既存の検出結果より上位に表示されます。次に diff_shape に1行で示される risk_percentile を確認します（これは最近のサンプルコミットを差分のサイズと広がりで比較した順位であり、バグ予測ではありません）。include=["scales"] を指定すると、review_priority の三分位と classification ラベルが追加されます。生の 0-10 の score は、追加行数に対して 0.99 の順位付けを行うため、出力には含まれず、include=["diagnostics"] の後に表示されます。 未コミットの作業をスコアリングするには revspec を省略します。これはマージ前のゲートとして、「この変更全体のリスクはどの程度か？」を確認するものです。すでにターミナルを使っている場合は、repowise risk <revspec> CLI でも同じスコアリングを行えます。
• get_risk(changed_files=…)（MCP） は ファイルごと に処理し、差分内で確認すべき具体的な項目を示す directive ブロックを返します。

まず変更全体をスコアリングする

get_change_risk(revspec="main..HEAD")   # HEAD, a commit SHA, or base..head

まず directive を確認します。status、悪化した点を示す headline、その背景にある reasons、実行すべき next_actions が含まれています。health_delta には、この変更によって発生または解消された検出結果が含まれます。次に risk_percentile と主な要因を確認します。広範囲への波及（多数のディレクトリやサブシステム）や作者の習熟度の低さによってスコアが高い場合、どこを重点的に確認すべきかが分かります。extensions=[".py", ".ts"] は指定されたファイルタイプのみを集計し、exclude_patterns=["tests/"] は該当するパスを除外します。warning フィールドがある場合、または directive.status が unknown の場合は、revspec またはフィルターに一致するファイルがなかったことを意味します。そのため、スコアがすべてゼロでも問題がないとは限りません。ターミナルでは repowise risk <revspec> で同じ処理を行えます（--ext .py,.ts または --format json を追加できます）。

次に、ファイルごとの指示を詳しく確認します

変更されたファイルを渡して、PR モードで get_risk を呼び出します：

get_risk(targets=<changed files>, changed_files=<same changed files>)

レスポンスには、変更ごとではなくファイルごとの directive ブロックが含まれます（get_change_risk のものとは異なります）。まずこれを確認してください。短いリストがいくつかあります：

• may_break — 変更された箇所にインポート経由でたどり着くファイル／シンボルのうち、差分に含まれていないものです。差分ではなく到達可能性を示します。つまり、これらが変更されたファイルに依存しているという意味であり、利用しているものが変更されたという意味ではありません。それぞれ確認してください。
• missing_cochanges — 変更されたファイルと過去に一緒に変更されていたものの、今回変更されなかったファイルです。更新漏れのことがよくあります。
• missing_tests — テストが不足している変更コードです。新規テストまたは更新テストを提案してください。
• tests_to_run：変更に必要なテストです。repowise impacted-tests が選ぶものと同じで、tests_to_run_why に各テストの理由（変更されたファイルとその根拠、または「すべてのサブセットで実行」）が示されます。まず tests_run_all を確認してください。これが true の場合、より小さなテストセットの実行を保証できません。tests_run_all_reasons にその理由が示され、リストは最初に実行するテストのみです。テストスイート全体を推奨してください。false の場合、リストにあるテストが実行すべきセットです。tests_to_run_basis は、変更されたファイルの判定に保存済みのテストごとのカバレッジを使った場合は measured、依存関係グラフまたはルールのみを使った場合は inferred です。どちらかを明記してください。選択できなかった場合（timeout、config_invalid、unknown など）に限り、tests_status が表示されます。その場合はすべてのテストを実行する必要があります。

get_change_risk には、impacted_tests として同じ結果が含まれます。status（selected、run_all、または何も選択されなかった理由）、run_all、reasons、tests_to_run、why です。get_risk に include=["blast"] を指定すると、指示リストの根拠となる、より詳細な情報をまとめた pr_blast_radius が追加されます。

ターミナルから行単位で正確に確認するには、repowise impacted-tests <revspec> を使います。変更された各行を、記録済みのカバレッジがその行に触れているテストに対応付けたうえで、テスト ID を出力します（--format list | xargs pytest で該当するテストだけを実行できます）。カバレッジの不足も明示されます。カバレッジ行がない変更ファイルは、ファイル名による推測としてラベル付けされ、新規ファイルは「不明。テストスイート全体を実行」となり、「テスト不要」とは判断されません。

重要な箇所をさらに詳しく確認します

1. このコードはなぜ存在するのでしょうか？ 重要な変更ファイルについては、get_why(query="<file>") を呼び出します。記録されたアーキテクチャ上の決定と、変更が知らないうちに矛盾しないようにしてください。conflicts_with／supersedes の該当項目を提示します。
2. 変更によって健全性が損なわれていないでしょうか？ get_health(targets=<changed files>, include=["biomarkers"]) を呼び出し、差分によって新たに生じた複雑さ、深いネスト、重複を指摘します。
3. 誰にレビューを依頼すべきでしょうか？ get_risk の所有者情報と共同変更のシグナルを手がかりに、変更箇所について最も詳しい人を選びます。

差分の取得

• GitHub PR：gh pr diff <number>（または gh pr view <number> --json files）。
• ブランチ：git diff --name-only main...HEAD。
• 作業ツリー：git status --porcelain。
• 範囲指定の CLI ショートカット：repowise risk main..HEAD を使うと、ブランチ／PR の範囲を対象に、欠陥リスクを直接スコアリングできます。

根拠を軸にレビューをまとめます

まずリスクレベルと、具体的なファイルに結び付けた directive の指摘事項を示します。「影響する可能性がある」（差分外の依存ファイル）と**「確認する価値がある」**（共同変更または健全性の悪化）を区別してください。ツールが裏付けていない指摘で内容を水増ししないでください。

エラー処理

get_risk がエラーを返すか、何も返さない場合、MCP サーバーがダウンしているか、リポジトリが未インデックスの可能性があります。その旨を伝え、生の差分からレビューを行い、Repowise のコンテキストが利用できなかったことを明記してください。リポジトリがインデックスされていない場合は、/repowise:init を提案してください。