pr-review

PR レビュー

5 つの観点で差分ベースのコードレビューを行います。変更されたファイルを読み込み、適用可能なレビュー手法を選択し、重要度順にランク付けした指摘事項をまとめたレポートを作成します。

ネイティブの代替手段： Claude Code の /ultrareview は、バグに焦点を当てた軽量なネイティブレビューを実行します（Opus 4.7 のリリース時点で、Pro／Max プランでは月 3 回無料）。ファイルと行番号を参照しながら、5 つの観点（コード品質＋テスト＋エラー処理＋型＋コメント）で重要度順にランク付けした分析を行うには、このスキルを使用してください。差分を手早くバグ検出するには /ultrareview を使用してください。

参照ファイル

ファイル	内容	読み込む条件
references/code-review.md	ガイドラインへの準拠、バグ検出、信頼度スコアリング	常に
references/test-analysis.md	振る舞いに対するテストカバレッジ、重要度評価	テストファイルが変更された場合
references/error-handling.md	失敗の見落としパターン、catch ブロックの分析	エラー処理が変更された場合
references/type-design.md	不変条件の分析、4 つの観点による評価基準	型定義が追加／変更された場合
references/comment-quality.md	コメントの正確さ、長期的な価値、陳腐化の検出	コメントが追加された場合

---

ワークフロー

フェーズ 1：範囲

1. レビュー対象を決定します。
   • デフォルト：git diff（ステージングされていない変更）
   • ユーザーが PR を指定した場合：git diff main...HEAD または gh pr diff <number>
   • ユーザーがファイルを指定した場合：それらのファイルを直接レビューします
2. git diff --name-only ですべての変更ファイルを一覧表示します
3. プロジェクトの CLAUDE.md があれば読み込み、プロジェクト固有のルールを確認します

フェーズ 2：振り分け

変更されたファイルを分類し、適用する観点を選択します。

条件	観点	読み込む参照ファイル
常に	コードレビュー	references/code-review.md
*test*、*spec*、*_test.*、test_* に一致するファイル	テスト分析	references/test-analysis.md
try/catch、except、.catch、Result、エラーコールバックを含むファイル	エラー処理	references/error-handling.md
class、interface、type、struct、enum、dataclass の定義を含むファイル	型設計	references/type-design.md
新規／変更された docstring、JSDoc、またはブロックコメントを含むファイル	コメント品質	references/comment-quality.md

該当する参照ファイルのみ読み込みます。一致するファイルがない観点は省略します。

フェーズ 3：レビュー

適用する各観点について、読み込んだ手法を使って差分を分析します。

1. コードレビュー — 変更された各ファイルを調べ、ガイドライン違反やバグがないか確認します。 信頼度を 0～100 で評価します。80 以上の問題のみ報告します。
2. テスト分析 — テストカバレッジを変更されたコードパスに対応付けます。不足を 1～10 で評価します。 5 以上の不足のみ報告します。
3. エラー処理 — 差分内のすべてのエラーハンドラーを調べ、失敗の見落としがないか確認します。 CRITICAL／HIGH／MEDIUM に分類します。
4. 型設計 — 新規または変更された型を 4 つの観点（カプセル化、不変条件の表現、有用性、強制力）で評価します。それぞれを 1～10 で評価します。
5. コメント品質 — 正確さを確認し、長期的な価値を評価し、コメントの陳腐化を指摘します。

フェーズ 4：集約

すべての指摘を重複排除し、重大度順に並べて 1 つのレポートにまとめます。

重複排除のルール：

• 2 つの観点で同じファイルの同じ行が指摘された場合は、重大度の高い方を残します
• コードレビューとエラーハンドリングの両方で空の catch ブロックが指摘された場合は、エラーハンドリングの重大度で 1 つの指摘にまとめます（この観点の方が専門的です）

観点間での重大度の対応：

観点	Critical に対応	Important に対応	Suggestion に対応
コードレビュー	Confidence 90-100	Confidence 80-89	—
テスト分析	Rating 9-10	Rating 7-8	Rating 5-6
エラーハンドリング	CRITICAL	HIGH	MEDIUM
型設計	評価が 3/10 以下	評価が 4-6/10	Rating 7-8/10
コメントの品質	事実に反する	誤解を招く、または不完全	明らかなコードの言い換え

---

出力形式

# PR Review Summary

**Scope:** [X files changed, Y dimensions applied]
**Dimensions:** [list of active dimensions]

## Critical Issues (must fix before merge)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Important Issues (should fix)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Suggestions (consider)
- **[dimension]** `file:line` — Description.

## Strengths
- What's well-done in this changeset.

## Recommended Action
1. Fix critical issues
2. Address important issues
3. Consider suggestions
4. Re-run review after fixes

いずれの重大度でも問題が見つからなかった場合は、確認した内容と適用した観点を簡潔にまとめ、コードが基準を満たしていることを伝えます。

---

観点の選択

ユーザーは、すべての観点を実行する代わりに、特定の観点を指定できます。

ユーザーの依頼	適用する観点
「PR をレビューして」／「変更を確認して」	該当するすべて（デフォルト）
「コードをレビューして」／「コードの品質を確認して」	コードレビューのみ
「テストを確認して」／「テストカバレッジは十分？」	テスト分析のみ
「エラーハンドリングを確認して」／「サイレント障害を見つけて」	エラーハンドリングのみ
「型をレビューして」／「型設計を確認して」	型設計のみ
「コメントを確認して」／「ドキュメントをレビューして」	コメントの品質のみ

特定の観点が指定された場合は、該当する参照ファイルのみを読み込み、振り分け処理を省略します。

---

エラーハンドリング

問題	対応
git diff が利用できない	対象のファイルまたは範囲を指定するようユーザーに依頼します
CLAUDE.md が見つからない	一般的なベストプラクティスに基づいてレビューし、見つからなかったことを記載します
diff にテストファイルがない	テスト分析の観点を省略し、出力にその旨を記載します
diff が空	「レビュー対象の変更はありません」と報告して終了します
diff がコンテキストの上限を超える	ユーザーが最も関心を持つと思われるファイルに絞り、スキップしたファイルを要約します

---

評価基準

1. 再現率より適合率を重視します。 偽陽性はレビューへの信頼を損ないます。信頼度（コードレビュー）が 80 以上、または重大度（テスト）が 5 以上の問題のみ報告します。ノイズを増やすより、報告しない方が望ましいです。
2. ファイルと行の指定は必須です。 すべての指摘に、具体的な場所を含める必要があります。「エラーハンドリングの改善を検討してください」のような曖昧な指摘は、対応につながりません。
3. プロジェクトのルールを一般的なルールより優先します。 CLAUDE.md に「アロー関数を使う」と記載されている場合、一般的なスタイルとして function 宣言が好まれていても、アロー関数を指摘しないでください。
4. 重複排除は必須です。 2 つの観点で同じ問題が指摘された場合は、1 つにまとめます。同じ問題を 2 回報告してはいけません。
5. 良い点にも触れます。 問題点だけを列挙するレビューは、意欲を損ないます。簡潔でもよいので、適切にできている点を記載します。
6. 簡素化は code-refiner が担当します。 このスキルはレビューと報告を行います。リファクタリングや簡素化は行いません。それらは code-refiner スキルの役割です。それぞれの役割を分けてください。

合理化

合理化	実態
「テストが通ったので、コードに問題はありません」	テストは必要ですが、それだけでは不十分です。アーキテクチャ、セキュリティ、可読性、保守性に関する問題を見逃します
「差分が小さいので、本格的なレビューは必要ありません」	本番環境でのインシデントの多くは小さな変更が原因です。認証を回避する3行の変更は、300行のリファクタリングより深刻です
「あとで整理します」	「あとで」は決して来ません。レビューは、コードがレガシー化する前の品質ゲートです
「著者はシニアなので、信頼しています」	経験が豊富でもミスは防げません。新鮮な視点が、慣れによって見えなくなったものを見つけます
「最近、似たコードをレビューしました」	各差分には固有の背景があります。過去のレビューでの思い込みが、問題の見落としにつながります
「これは単なるリファクタリングなので、何も壊れません」	リファクタリングは、微妙な形で動作を変えることがあります。テストと呼び出し元の追跡で検証してください

危険信号

• 変更されたすべてのファイルを全文読まずに承認する（差分の一部だけで済ませない）
• 指摘事項にファイル名と行番号の参照がない。曖昧なフィードバックは対応につながりません
• 「問題なさそうだから」という理由で、レビューの観点を省略する
• ロジック、セキュリティ、アーキテクチャを無視し、スタイル上の問題だけを報告する
• 生成コード（マイグレーション、protobuf スタブ）を、手書きコードと同じ厳しさでレビューする
• 重複を除去せず、異なる観点からの指摘をまとめる

検証

• 差分の一部だけでなく、変更されたすべてのファイルを全文読んだ
• 各レビュー観点を評価した：正確性、セキュリティ、パフォーマンス、可読性、アーキテクチャ
• すべての指摘にファイル名と行番号の参照が含まれている
• 変更行数100行につき、少なくとも1件の実行可能な指摘がある。または、理由を明示して「問題は見つかりませんでした」と記載している
• レビューの概要にリスクレベル（LOW/MEDIUM/HIGH/CRITICAL）と、ブロッキングか非ブロッキングかの区分が含まれている
• 良い点も認めている。レビューが100％否定的になっていない