PRやコード変更の汎用コードレビューを実施します。コードの品質、セキュリティ、設計を共通基準で評価し、approve/rejectを判断します。「このPRをレビュー」「コードレビューして」「マージ前チェック」などの依頼や、gh pr viewコマンドの実行時に使用してください。

コードレビュー PRやコード変更を体系的にレビューするための汎用スキルです。言語非依存の共通レビュー基準と、言語/フレームワーク固有のベストプラクティスを組み合わせて使用します。ディレクトリ構成ランタイムファイル CI実行時に自動生成されるファイル。リポジトリにはコミットしない。ファイル用途ライフサイクル .pr triage.json トリアージ結果毎回生成 .pr review state.json レビュー状態 actions/cache で実行間永続化外部スキル連携 React / Next.js のベストプラクティスは、Vercel提供の vercel react best practices スキルを使用する。リポジトリ : https://github.com/vercel labs/agent skills/tree/main/skills/react best practices インストール : npx y skills add vercel labs/agent skills skill vercel react best practices agent claude code yes カバー範囲 : 非同期ウォーターフォール排除、バンドルサイズ最適化、サーバー側パフォーマンス、クライアント側データ取得、再レンダリング最適化、レンダリングパフォーマンス、高度なパターン、JavaScriptパフォーマンス（8カテゴリ、40以上のルール）コスト最適化（CI環境） GitHub Actions等のCI環境で実行する場合、トリアージフェーズを軽量モデル（Haiku）に委任することでコストを大幅に削減できる。詳細は [references/ci optimized workflow.md](references/ci optimized workflow.md) を参照。トリアージ結果の活用 CI環境で事前トリアージが実行されている場合、作業ディレクトリに .pr triage.json が存在する。このファイルが存在する場合、以下の最適化を適用する： 1. ステップ1をスキップ — トリアージ結果の summary を使用する 2. リファレンスの選択的読み込み — required references に含まれるものだけを読む 3. 表層チェックの省略 — surface issues に含まれるMinor/Suggestion問題は既にチェック済みとして、Critical/Major分析に集中する 4. 差分の効率的な確認 — files のカテゴリ分類を活用し、重要度の高いファイルから優先的にレビューする .pr triage.json が存在しない場合は、従来通りステップ1から全ステップを実行する（後方互換性あり）。インクリメンタルレビュー（PR更新時の差分最適化） PR更新（ synchronize イベント）時に、前回のレビュー状態を活用してトークン消費を削減する。詳細は [references/incremental review.md](references/incremental review.md) を参照。 .pr review state.json が存在しない場合（初回レビュー）は、インクリメンタル最適化は適用されず、フルトリアージを実行する。不正な形式の場合も警告を出力してフルトリアージを実行する。レビューワークフロー以下のチェックリストをコピーして進行状況を追跡します：ステップ1: 変更概要の把握 .pr triage.json が存在する場合 : このファイルを読み込み、 summary 、 files 、 change categories 、 diff summary を使用する。以下の手動確認はスキップしてステップ2へ進む。変更内容を理解する。 1. 変更ファイル一覧を確認変更の範囲とスコープを把握 2. コード差分を確認追加・変更・削除された内容を把握 3. 変更の意図を理解 PR説明やコミットメッセージから目的を確認確認すべきポイント：変更は単一の目的にフォーカスしているかスコープが適切か（1つのPRで多すぎる変更をしていないか）関連する変更が漏れなく含まれているかステップ2: 共通品質チェック .pr triage.json が存在する場合 : surface issues に含まれるMinor/Suggestionの問題は既にチェック済み。ここではCritical/Majorレベル（セキュリティ、ロジック・正確性、パフォーマンスの重大問題）の検出に集中する。表層的な問題（命名規則、デストラクチャリング等）は再チェック不要。言語に依存しない汎用的なチェックを実施する。 2 1. セキュリティチェック項目重要度ハードコードされた秘密情報（APIキー、パスワード、トークン）がないか Critical ユーザー入力の適切なバリデーション・サニタイズがあるか Critical SQLインジェクション、XSS、コマンドインジェクションの脆弱性がないか Critical 認証・認可のチェックが適切に実装されているか Critical 機密データが不用意にログ出力されていないか Major CORS設定が適切か Major 認可（Authorization）の詳細レビュー：認可に関わる変更がある場合は、[references/authorization review general.md](references/authorization review general.md) を参照して詳細なチェックを行う。PostgreSQL RLSを使用している場合は、追加で [references/authorization review postgres rls.md](references/authorization review postgres rls.md) も参照する。 2 2. ロジック・正確性チェック項目重要度エッジケースが適切に処理されているか（null、空配列、境界値） Major エラーハンドリングが適切か（例外の握りつぶし、不適切なcatch） Major 条件分岐のロジックが正しいか（off by one、論理演算子の誤り） Major 非同期処理の競合状態（race condition）がないか Major リソースの確実な解放（ファイル、接続、ロック） Major 2 3. 設計・保守性チェック項目重要度関数/メソッドの責務が単一か Minor DRY原則: 不要な重複コードがないか Minor 命名が意図を正確に表しているか Minor マジックナンバーや意味不明な文字列リテラルがないか Minor 適切な抽象度で設計されているか（過剰な抽象化・不足） Minor 循環参照・不適切な依存関係がないか Major 2 4. パフォーマンスチェック項目重要度 N+1クエリなど非効率なデータアクセスパターンがないか Major 不要なループやネスト、計算量の大きい処理がないか Minor メモリリークの可能性がないか Major 大量データの適切なページネーション・ストリーミング処理 Minor 2 5. テストチェック項目重要度変更に対応するテストが追加/更新されているか Major エッジケースのテストが含まれているか Minor テストが実装詳細でなく振る舞いをテストしているか Minor テスト名がテスト対象の振る舞いを明確に表しているか Suggestion ステップ3: 言語/フレームワーク固有チェック .pr triage.json が存在する場合 : required references に記載されたリファレンスのみを読み込む。リストにないリファレンスは読み込まない（トークン節約）。変更ファイルの言語/フレームワークに応じて、対応するリファレンスファイルを参照する。参照可能なリファレンス：言語/FW 参照先種別 TypeScript [references/typescript best practices.md](references/typescript best practices.md) 内部リファレンス React / Next.js vercel react best practices スキル（Vercel提供）外部スキル観点参照先種別認可（一般） [references/authorization review general.md](references/authorization review general.md) 内部リファレンス認可（PostgreSQL RLS） [references/authorization review postgres rls.md](references/authorization review postgres rls.md) 内部リファレンス GitHub PRレビュー [references/github pr review actions.md](references/github pr review actions.md) 内部リファレンス Claude Codeスキル [references/skill review.md](references/skill review.md) 内部リファレンス参照ルール： TypeScriptの変更 → 内部リファレンスを読み込む React / Next.js の変更 → vercel react best practices スキルを併用する（インストール済みの場合）認可に関わる変更（認証/権限チェック、データアクセス制御等） → 認可リファレンス（一般編）を参照 PostgreSQL RLSを使用している場合 → 認可リファレンス（RLS編）も追加で参照 GitHub Actions等のCI環境でPRレビューを実行する場合 → GitHub PRレビューアクションを参照（コメント投稿・評価方法） SKILL.mdファイルが含まれる変更 → スキルレビューリファレンスを参照し、スキル品質チェックを追加実施する複数の言語/FWにまたがる変更の場合は、すべての該当リファレンスを参照するリファレンスが存在しない言語の場合は、ステップ2の共通チェックのみで判断するステップ4: approve/reject判定すべてのチェック結果に基づき、以下の基準でapprove/rejectを判定する。問題の重要度と減点重要度説明減点 Critical マージ前に必ず修正が必要。セキュリティ脆弱性、データ損失リスク、重大なバグ 3点/件 Major 優先的に修正すべき。ロジックの問題、パフォーマンス劣化、テスト不足 2点/件 Minor 改善が望ましい。設計改善、可読性向上、軽微な問題 1点/件 Suggestion 提案。ベストプラクティスの推奨、より良いアプローチの提示 0.5点/件判定基準満点は10点とし、以下の基準で判定する。判定条件アクション Reject Critical問題が1件以上ある REQUEST CHANGES Reject Major問題が3件以上ある REQUEST CHANGES Reject スコアが5点未満 REQUEST CHANGES Conditional Approve Critical問題なし、Major 1 2件、スコア5点以上 APPROVE（改善点をコメント） Approve Critical/Major問題なし、スコア8点以上 APPROVE 判定フローチャートステップ5: レビュー結果の出力 .pr triage.json が存在する場合 : トリアージフェーズの surface issues をレビュー結果の「検出された問題」テーブルにマージする（重複を除外）。スコアリングにはトリアージの指摘も含める。以下のフォーマットでレビュー結果を出力する。 GitHub上でのレビュー投稿：GitHub Actions等のCI環境でPRレビューを実行している場合のみ、[references/github pr review actions.md](references/github pr review actions.md) を参照して、 gh コマンドやインラインコメントを使用してレビュー結果をGitHub上に投稿する。ローカル環境での実行時は、結果を標準出力に表示するのみとする。修正済み問題のフォローアップ： .pr triage.json に resolved issues が含まれる場合（インクリメンタルレビュー時）、元のインラインコメントにリプライして修正を報告する。レビュー完了後、投稿したコメントIDを .pr review state.json に記録する。重要な注意事項レビューはコードの品質向上が目的であり、批判ではない。建設的なフィードバックを心がける問題の指摘には必ず具体的な改善案を添える変更の意図を尊重し、スタイルの好みではなく客観的な基準で判断する自動検出が困難なドメイン知識やビジネスロジックの判断は、人間のレビュアーに委ねる Suggestionは強制ではなく、採用するかどうかは著者の判断に任せる

code-review