コードレビュー

PRやコード変更を体系的にレビューするための汎用スキルです。 言語非依存の共通レビュー基準と、言語/フレームワーク固有のベストプラクティスを組み合わせて使用します。

ディレクトリ構成

code-review/
├── SKILL.md (このファイル)
└── references/
    ├── typescript-best-practices.md       # TypeScript固有のチェック
    ├── authorization-review-general.md    # 認可レビュー観点（一般編）
    ├── authorization-review-postgres-rls.md  # 認可レビュー観点（PostgreSQL RLS編）
    └── github-pr-review-actions.md        # GitHub PRレビューアクション

外部スキル連携

React / Next.js のベストプラクティスは、Vercel提供の react-best-practices スキルを使用する。

• リポジトリ: https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices
• インストール: npx add-skill vercel-labs/agent-skills
• カバー範囲: 非同期ウォーターフォール排除、バンドルサイズ最適化、サーバー側パフォーマンス、クライアント側データ取得、再レンダリング最適化、レンダリングパフォーマンス、高度なパターン、JavaScriptパフォーマンス（8カテゴリ、40以上のルール）

レビューワークフロー

以下のチェックリストをコピーして進行状況を追跡します：

レビュー進捗：
- [ ] ステップ1: 変更概要の把握
- [ ] ステップ2: 共通品質チェック
- [ ] ステップ3: 言語/フレームワーク固有チェック
- [ ] ステップ4: approve/reject判定
- [ ] ステップ5: レビュー結果の出力

ステップ1: 変更概要の把握

変更内容を理解する。

1. 変更ファイル一覧を確認 – 変更の範囲とスコープを把握
2. コード差分を確認 – 追加・変更・削除された内容を把握
3. 変更の意図を理解 – PR説明やコミットメッセージから目的を確認

確認すべきポイント：

• 変更は単一の目的にフォーカスしているか
• スコープが適切か（1つのPRで多すぎる変更をしていないか）
• 関連する変更が漏れなく含まれているか

ステップ2: 共通品質チェック

言語に依存しない汎用的なチェックを実施する。

2-1. セキュリティ

認可（Authorization）の詳細レビュー：認可に関わる変更がある場合は、references/authorization-review-general.md を参照して詳細なチェックを行う。PostgreSQL RLSを使用している場合は、追加で references/authorization-review-postgres-rls.md も参照する。

2-2. ロジック・正確性

2-3. 設計・保守性

2-4. パフォーマンス

2-5. テスト

ステップ3: 言語/フレームワーク固有チェック

変更ファイルの言語/フレームワークに応じて、対応するリファレンスファイルを参照する。

参照可能なリファレンス：

参照ルール：

• TypeScriptの変更 → 内部リファレンスを読み込む
• React / Next.js の変更 → react-best-practices スキルを併用する（インストール済みの場合）
• 認可に関わる変更（認証/権限チェック、データアクセス制御等） → 認可リファレンス（一般編）を参照
• PostgreSQL RLSを使用している場合 → 認可リファレンス（RLS編）も追加で参照
• GitHub Actions等のCI環境でPRレビューを実行する場合 → GitHub PRレビューアクションを参照（コメント投稿・評価方法）
• 複数の言語/FWにまたがる変更の場合は、すべての該当リファレンスを参照する
• リファレンスが存在しない言語の場合は、ステップ2の共通チェックのみで判断する

ステップ4: approve/reject判定

すべてのチェック結果に基づき、以下の基準でapprove/rejectを判定する。

問題の重要度と減点

判定基準

満点は10点とし、以下の基準で判定する。

判定フローチャート

Critical問題あり？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
Major問題が3件以上？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
スコア5点未満？ → Yes → Reject（REQUEST_CHANGES）
       ↓ No
Major問題が1-2件？ → Yes → Conditional Approve
       ↓ No
スコア8点以上？ → Yes → Approve
       ↓ No
Conditional Approve

ステップ5: レビュー結果の出力

以下のフォーマットでレビュー結果を出力する。

GitHub上でのレビュー投稿：GitHub Actions等のCI環境でPRレビューを実行している場合のみ、references/github-pr-review-actions.md を参照して、ghコマンドやインラインコメントを使用してレビュー結果をGitHub上に投稿する。ローカル環境での実行時は、結果を標準出力に表示するのみとする。

## Code Review: [判定結果]

### 変更概要
- **スコープ**: [変更の概要を1-2文で]
- **変更ファイル数**: [N]ファイル
- **主な言語/FW**: [検出された言語/FW]

### スコア: X/10

### 検出された問題

| # | 重要度 | ファイル | 問題 | 推奨される対応 |
|---|--------|---------|------|---------------|
| 1 | [Critical/Major/Minor/Suggestion] | [ファイルパス:行番号] | [問題の説明] | [対応方法] |

### 良い点
- [コードの良い点を具体的に記載]

### 判定
- **結果**: [Approve / Conditional Approve / Reject]
- **理由**: [判定理由の要約]

### 次のステップ
- [修正が必要な場合の具体的なアクション]

重要な注意事項

• レビューはコードの品質向上が目的であり、批判ではない。建設的なフィードバックを心がける
• 問題の指摘には必ず具体的な改善案を添える
• 変更の意図を尊重し、スタイルの好みではなく客観的な基準で判断する
• 自動検出が困難なドメイン知識やビジネスロジックの判断は、人間のレビュアーに委ねる
• Suggestionは強制ではなく、採用するかどうかは著者の判断に任せる