gh-pr-review

/gh-pr-review — コードレビュー

ローカルブランチ、PR、コミット、ファイルに対する自動コードレビューです。引数からレビュー対象を検出し、差分サイズと実行環境の能力に基づいてレビューエンジンを選択します。小さな差分では単一エージェントレビュー(references/local-review.md)を使用します。大きな差分では、独立したサブエージェントが利用可能な場合に限り、マルチエージェントのレビュアー–検証者フロー(references/teams-review.md)を使用します。それ以外の場合は、その制約を開示したうえで単一エージェントレビューにフォールバックします。PR を対象とする場合は、同じエンジン選択の契約に加えて、ワークツリーのセットアップと GitHub への送信(references/pr-review.md)が追加されます。

Cherry Studio 固有のレビュールールは references/cherry-review-guidance.md にあります。対象のレビューフローは、コード、混在、アーキテクチャドキュメント、プロジェクトスキルのレビューにおいてこのファイルを読み込む必要があります。これにより、レビュアーは記憶に頼ることなく DataApi、サービス境界、レンダラーフック、React、UI、型契約のチェックを適用できます。このリファレンスは、変更された領域ごとに参照すべき内部ドキュメント、内部スキル、外部スキル、公式ウェブサイトも定義しています。関連するサブセットのみを読み込んでください。

すべてのユーザー向けテキストはユーザーの言語に一致させます。

対話と中断の契約

以下に宣言されたカテゴリを除き、通常のレビューはプロンプトなしで進行します。モード選択、修正の確認、検出事項の選択、送信プレビューを求めてはいけません。リーフフローが入力を要求できるのは、次のカテゴリのいずれかを明示的に宣言した場合のみです。

• プロダクトの意思決定 — 対話セッションでは、プロダクトデマンドゲートが、レビューでは導出できない意思決定を現在のユーザーに求めることがあります。自動セッションでは、ユーザーの代わりに決定を下すことなく、影響と未解決の意思決定を記録します。
• 安全性または環境のブロッカー — 続行するには破壊的な操作、新たな権限、または不足している外部設定が必要になります。宣言された例は、ダーティまたは不一致のレビューワークツリー、正規のリモートの欠如、説明のつかない変更のクリーンアップ、失敗した修正パッチの削除、および今回の実行では確認していないコメントを保持している保留中のレビュードラフトです。対話セッションでは、状態を保持し、続行に必要な意思決定のみを求めます。
• 明示的なメンテナンスモード — diag および別途要求されたチェックリストのメンテナンスは、通常のレビュー外にある対話的な選択フローです。宣言された編集の選択、または永続的なチェックアウト/ブランチの対象を求めることがあります。

自動セッションはユーザー入力を待ちません。プロダクトの意思決定では、以下に規定するとおり記録のみを続行します。安全性/環境のブロッカーでは、状態を保持し、影響を受けるフローを安全に停止し、正確なブロッカーと必要な意思決定を報告します。明示的なメンテナンスモードでは、候補または不足している送信先情報を報告し、選択に依存する編集を適用せず、安全に停止します。いかなるリーフフローも、別のプロンプトカテゴリを導入してはいけません。

レビューステージ

すべてのレビューは、これらのステージを順番に実行します。後続のステージは、先行するステージを通過したものだけをレビューするため、あるステージが先行する判定を再び争うことはありません。

この表は、ステージの範囲と参照先に関する唯一の信頼できる情報源です。リーフフローがステージを拡大したり、縮小したり、参照先を変更したりすることはできません。

#	ステージ	適用対象	参照先
1	プロダクト需要（ゲート）	セマンティクスがプロダクトに影響するあらゆる変更	下記
2	コンシューマー	共有サーフェスを追加または拡大するあらゆる変更	references/consumer-review.md
3	アーキテクチャファースト	コード、混在、Cherry アーキテクチャドキュメント、プロジェクトスキル	references/cherry-review-guidance.md
4	実装	コード、混在	references/code-checklist.md（A/B）
4	実装	ドキュメント	references/doc-checklist.md（A/B）
5	スタイル / 規約	コード、混在	references/code-checklist.md（C）
5	スタイル / 規約	ドキュメント	references/doc-checklist.md（C）

ステージの適用可否は、コミットのラベルではなく、変更された内容に従います。ドキュメントのみの差分であっても、Cherry アーキテクチャドキュメントやプロジェクトスキルを変更する場合はステージ 3～5 を実行し、ドキュメントも編集するコード差分は、ステージ 4～5 で両方の参照セットを実行します。

ステージ 1: プロダクト需要ゲート

まず、変更によって実際に表現または制約されるセマンティクスを調査し、それがプロダクトのセマンティクス、ユーザーに見える動作、またはプロダクトの方向性に影響するかどうかを判断します。変更ラベルは十分な証拠にはなりません。内部リファクタリングやユーザーに直接関係しない修正はプロダクトに影響しないことが多い一方で、ユーザーに直接関係する修正、ドキュメント、テスト、ツールは、プロダクトの動作を記録、固定、または変更することがあります。

プロダクトへの影響がある場合は、その方向性が現在のレビューコンテキストですでに確立されているかどうかを判断します。確立済みと見なすのは、現在のユーザーが明示的に決定した場合、または権威あるプロジェクト成果物が、受け入れられた動作と、仕様書、ADR、期待される動作を確定するメンテナーの決定を含む Issue など、責任あるプロジェクト権限によるその承認を明示的に記録している場合だけです。Issue の状態、ラベル、マイルストーン、担当者の割り当て、または PR からのリンクから承認を推測してはいけません。変更ラベル、PR 本文、実装、またはテストは、作者の意図や現在の動作を示すものですが、それ自体でプロダクトの承認を確立するものではありません。

ゲートを正確に 1 つの状態に分類します:

• プロダクトへの影響なし: 対話型実行と自動実行の両方で、このステージを完全にスキップします。スキップしたゲートについて何も言及しません。
• 方向性が確立済み: 変更を記録された決定と比較します。整合していれば、別のプロダクト判断を求めることなく続行します。矛盾していれば、プロダクトの方向性の不一致を報告し、レビュー全体を直ちに停止します — コンシューマー、アーキテクチャ、実装、スタイルの各ステージを実行せず、コードの指摘も報告しません。既存の決定を適用することは、新しい決定を行うことではありません。
• プロダクト判断が未解決:
  • 対話型セッション（デフォルト）: プロダクトの機能とセマンティクスに対する変更の影響を要約し、未解決のプロダクト判断について現在のユーザーに尋ねます。PR の作成者、レビューの担当者、またはユーザーが変更を作成したかどうかから自動化を推測してはいけません。ユーザーが方向性を拒否した場合は、上記と同様にレビュー全体を停止します。ユーザーが承認した場合は、残りのステージを続行します。
  • 自動セッション（明示的な場合のみ）: このモードは、呼び出しプロンプトまたはワークフローコンテキストが、ヘッドレス、CI、バッチ、またはその他の自動実行を明示的に示している場合にのみ使用します。ユーザーに代わってプロダクト判断を行わないでください。残りのステージを実行し、最終レポートでプロダクトへの影響、変更が取る方向性、および人間による確認が必要な点を要約します。これをプロダクトの承認が得られたかのように表現してはいけません。

権限モデル

レビュー依頼は、分析と報告のみを許可します。レビュー対象、レビューの深さ、およびレビュアーと検証者の信頼度が実行権限を与えることは決してありません。権限は呼び出し時に明示的に付与され、実行がプロンプトなしで行われるのは、権限が付与された後だけです。

• 報告のみ（デフォルト）: すべてのレビュー、あらゆる対象 — 指摘は修正ガイダンスとともに報告されます。ワーキングツリーの編集も GitHub への書き込みも行いません。
• 修正（明示的）: 呼び出しによってのみ付与されます — $ARGUMENTS 内の fix、または同等の明示的なユーザーの文言（「レビューして修正して…」）。ローカル対象のみです。各リスクレベルで何が許可されるかは、references/judgment-matrix.md § Handling by Risk Level が規定します。このセクションは権限を付与するものであり、そのマッピングを再掲することは決してありません。 修正を適用すると、そのセッションはコーディングタスクになるため、以下の § 適用された修正後の検証 に従って選択された検証で終了しなければなりません。
• 送信（明示的）: 呼び出しによってのみ付与されます — $ARGUMENTS 内の submit、または同等の明示的なユーザーの文言。PR フローは、その後、コメントごとのプロンプトなしで、確認されたすべての指摘を送信します。承認またはマージには、常にそれ自体の明示的なリクエストが必要です。

適用された修正後の検証

何も編集しなかったレビュー中は、ローカルの lint、テスト、フォーマットを決して実行しないでください。修正が適用された場合は、変更されたサーフェスに一致する検証を、AGENTS.md § Operational Rules（「Check what you changed, not the whole repo」）に従って選択し、その結果を報告します。

• ドキュメント／Markdown のみの修正 — このスキル自身のファイルを含む — では、pnpm docs:check を実行します。
• コードの修正では、pnpm lint（これはすでに pnpm format で終わるため、format を再度呼び出さないでください）に加えて、変更をカバーするテストを実行します。たとえば pnpm test:main <file> や pnpm exec vitest run <file> のようなプロジェクトごとのラッパーです。pnpm test <path> は決して使わないでください — そのスクリプトは複数の vitest 呼び出しを連結しており、パスは最後の 1 つにしか届きません。
• 影響を受けるテストを特定できない広範な変更には、完全な pnpm test を取っておき、CI と同等の lint ゲートが重要な場合は pnpm test:lint を使用してください（pnpm lint は CI が拒否する oxlint の警告を許容します）。

ルート

まず $ARGUMENTS から権限修飾子を取り除きます（会話内の同等の明示的なユーザーの文言も同じように扱われます。どちらもデフォルトは false です）。残りを REVIEW_TARGET と呼びます — 以下のすべてのルール、およびすべてのリーフフローは、生の $ARGUMENTS ではなく、常に REVIEW_TARGET を読み取ります。

• fix → AUTHORIZED_FIX = true（ローカル対象に対して意味を持ちます）
• submit → AUTHORIZED_SUBMIT = true（PR 対象に対して意味を持ちます）

レビューエンジンを選択する前に、ランタイムが公開している協調機能を調べてください。独立したレビュアーと、新たな独立した検証者を起動できる場合にのみ、HAS_SUBAGENTS = true を設定します。並列実行は必須ではありません。逐次的なサブエージェントでも分離の契約を満たします。

ルール

上から順に、最初に該当するルールを適用します。

1. REVIEW_TARGET が diag → references/diagnosis.md。
2. REVIEW_TARGET が checklist である、またはユーザーが提案されたチェックリスト候補の採用を明示的に依頼した → references/checklist-evolution.md に進み、そのステップ 2 から開始します。メンテナンスは候補を生成したセッションでのみ実行され、何もレビューしません。
3. REVIEW_TARGET が PR 番号、または /pull/ を含む URL → references/pr-review.md(AUTHORIZED_SUBMIT と HAS_SUBAGENTS を渡します。ラッパーはエンジンを選択する前に正確な PR スコープを収集します)。
4. それ以外すべて: 以下の § スコープの導出に従ってスコープと SMALL_SCOPE を導出し、その後エンジンを選択します。
   • SMALL_SCOPE = true → references/local-review.md。
   • SMALL_SCOPE = false かつ HAS_SUBAGENTS = true → references/teams-review.md。
   • SMALL_SCOPE = false かつ HAS_SUBAGENTS = false → references/local-review.md。LIMITED_SINGLE_AGENT = true を渡し、大きな差分が独立した敵対的検証なしに単一エージェントによるレビューを受けたことをレポートで明示的に述べます。
   • AUTHORIZED_FIX を渡します(コミットおよび範囲ターゲットは不変の履歴です — フラグに関係なく常にレポートのみ)。

各 → は、対象ファイルを Read し、差分の取得方法、修正の適用方法、結果の提出方法に関する唯一の残りの指示としてそれに従うことを意味します。記憶や習慣からレビューしないでください。スキル全体のセクション — § レビューステージ、§ 権限モデル、§ 適用された修正後の検証、§ スコープの導出 — は引き続き拘束力を持ち、リーフフローはそれらを名前で参照します。

ルーティングのためにユーザーに何も尋ねないでください。REVIEW_TARGET、解決されたスコープ、SMALL_SCOPE、および権限フラグを対象ファイルに渡します。

スコープの導出

上記のルール 4 からのみ到達します。diag および checklist のターゲットがこの サブセクションに入ることはありません。これはレビュースコープとそのサイズがどのように 導出されるかについての唯一の所有者です — リーフフローはこれを参照し、決して再記述しません。

REVIEW_TARGET をレビュースコープに解決します:

REVIEW_TARGET	スコープ
空、コミットされていない変更が存在する	コミットされていない変更のみ — git diff HEAD (ステージ済み + 未ステージの追跡ファイル)、および git status --porcelain からの未追跡 (??) ファイルを、新しいコードとしてレビュー
空、クリーンなツリー	ベースとのブランチ差分: git merge-base origin/{main|master} HEAD、次に git diff <merge-base-sha>、および未追跡ファイル
コミットハッシュ	git rev-parse --verify で検証し、次に git show
コミット範囲 (A..B / A...B)	両方のエンドポイントを検証し、次に git diff A~1..B
ファイル/ディレクトリのパス	各パスの存在を確認し、次に解決されたファイルの全内容
PR 番号または /pull/ URL	PR のマージベース差分。references/pr-review.md によって収集されます

作業が存在するかどうかを決定するのは、diff ではなく解決されたレビュースコープです: パスターゲットの場合、それは指定されたパスから解決されたファイルの集合です。その他の すべてのターゲットの場合、それは diff です。クリーンなツリーであっても、パスターゲットが 空になることはありません。解決されたスコープが空の場合、以下に示す使用例を表示して終了します。

次に、リーフフローが実際に読み取るものを測定します — diff 形式のターゲットには diff、 パスターゲットには完全なファイルテキストです:

• Diff 形式のターゲット (コミットされていない変更、ブランチ/マージベース差分、コミット、 コミット範囲、PR): CHANGED_LINES は、完全なレビュースコープに対する git diff --numstat からの数値の追加と削除の合計であり、CHANGED_FILES はその中の 一意の変更パスの数です。
• ファイル/ディレクトリのパスターゲット: リーフフローは完全な内容をレビューするため、 完全な内容を測定します — CHANGED_FILES は、指定されたパスから解決されたファイルの数 (ディレクトリは再帰的に展開され、無視されたパスは除外されます) であり、 CHANGED_LINES はそれらのファイルの総行数です。クリーンなツリーであっても、パス ターゲットがデフォルトで小さくなることはありません。
• Diff 形式のスコープ内の未追跡テキストファイルは、それぞれ 1 ファイルとしてカウントされ、 その全行数が追加として扱われます。
• 生成されたファイルは両方の合計に通常どおりカウントされます。生成されたという理由で それらを除外しないでください。
• あらゆるバイナリファイル — バイナリ diff (--numstat の -/-)、未追跡のバイナリ、 またはパスターゲットから解決されたバイナリ — は 1 ファイルとしてカウントされ、その行数が 不明であるため、スコープを非スモールにします。

SMALL_SCOPE = true を設定するのは、CHANGED_LINES <= 1000、CHANGED_FILES <= 20、 かつスコープにバイナリファイルが含まれない場合のみです。両方の数値条件が成立する必要が あります。SMALL_SCOPE は、すべてのフローがこの結果に対して使用する名前です。

使用例

解決されたスコープが空の場合、このリストを表示します:

/gh-pr-review                      review uncommitted changes, else the branch diff
/gh-pr-review a1b2c3d              review a commit
/gh-pr-review a1b2c3d..e4f5g6h     review a commit range
/gh-pr-review src/foo.ts           review files or directories
/gh-pr-review 123                  review a PR (also accepts a /pull/ URL)
/gh-pr-review <target> fix         also apply low-risk fixes (local targets)
/gh-pr-review <pr> submit          also publish the review to GitHub
/gh-pr-review checklist            adopt this session's proposed checklist items
/gh-pr-review diag                 diagnose gaps in this skill