pr-review

PR レビュースキル

アップストリームのマージベースとの差分を分析し、プルリクエストを包括的にレビューします。

前提条件の確認（最初に必ず確認）

続行する前に、以下を確認してください。

# 1. Check if in a git repository
git rev-parse --is-inside-work-tree

# 2. Check if gh CLI is available and authenticated
gh auth status

いずれかの確認に失敗した場合は、作業を中止してユーザーに伝えてください。

• Git リポジトリではない場合 → 「このスキルを使用するには Git リポジトリが必要です。Git プロジェクトに移動してください。」
• gh が認証されていない場合 → 「最初に gh auth login を実行してください。」

入力

ユーザーは、以下のいずれかの形式で PR リンクを指定します。

• 完全な URL：https://github.com/owner/repo/pull/123
• 短縮形式（リポジトリ内の場合）：#123 または 123

ワークフロー

ステップ 1：PR 情報の抽出

# Get comprehensive PR metadata
gh pr view <PR_URL> --json number,title,body,state,author,baseRefName,baseRefOid,headRefName,headRefOid,additions,deletions,changedFiles,files,commits,reviewDecision,reviews,labels,milestone,createdAt,updatedAt

# Get the diff
gh pr diff <PR_URL>

# Get list of changed files
gh pr diff <PR_URL> --name-only

# Get detailed file changes with additions/deletions
gh api repos/{owner}/{repo}/pulls/{number}/files

ステップ 2：マージベースの分析

# Get base and head commits
BASE_REF=$(gh pr view <PR_URL> --json baseRefOid -q .baseRefOid)
HEAD_REF=$(gh pr view <PR_URL> --json headRefOid -q .headRefOid)

# Find merge base (requires local clone)
git fetch origin $BASE_REF $HEAD_REF 2>/dev/null || true
git merge-base $BASE_REF $HEAD_REF 2>/dev/null || echo $BASE_REF

ステップ 3：コードの詳細分析

変更された各ファイルについて、以下を分析します。

1. 差分全体を読む - すべての変更を把握します
2. 周辺のコンテキストを読む - gh api またはローカルファイルを使って、変更対象コードを理解します
3. パターンを特定する - このコードベースでは、どのようなコーディングパターンが使われていますか？
4. テストを確認する - 対応するテストの変更はありますか？

出力形式（必須）

レビューには、以下のセクションをすべて、この順序で含めてください。

---

📋 PR の概要

タイトル：[PR のタイトル] 作成者：[作成者] ブランチ：[head] → [base] 変更ファイル数：[N] | 追加：+[N] | 削除：-[N]

この PR の内容

[この PR の目的と範囲を説明する 2～5 文。追加・変更・削除される機能を具体的に記述してください。]

主な変更点

• [箇条書き 1：具体的な変更]
• [箇条書き 2：具体的な変更]
• [...]

---

📖 レビューのガイドライン

この PR の変更内容に基づき、レビュアーは以下の点を重点的に確認してください。

領域	優先度	確認事項
[領域 1]	🔴 高	[具体的なガイダンス]
[領域 2]	🟡 中	[具体的なガイダンス]
[領域 3]	🟢 低	[具体的なガイダンス]

---

🚨 発見された問題

問題は重大度順（Critical → High → Medium → Low → Nitpick）に並べます。

🔴 Critical（必ず修正）

[バグ、セキュリティ上の脆弱性、またはデータ損失を引き起こす問題]

[問題のタイトル]

• ファイル：path/to/file.ts:L123
• 問題：[問題を明確に説明]
• 影響：[何が起こるか]
• 提案：[修正方法]

🟠 High（修正を推奨）

[問題を引き起こす可能性があるもの、または重要なパターンに違反する問題]

🟡 Medium（修正を検討）

[コード品質の問題、軽微なバグ、またはパターン違反]

🟢 Low（改善すると望ましい）

[スタイル上の問題、軽微な改善]

💭 細かな指摘

[純粋にスタイル上の提案、任意の改善]

---

🧪 テストカバレッジの分析

この PR のテスト変更

テストファイル	種類	カバレッジ
[ファイル]	[unit/integration/e2e]	[テスト内容]

カバレッジの評価

• 新規コードのテスト：[Yes/No/Partial] - [説明]
• エッジケースのカバー：[Yes/No/Partial] - [説明]
• 回帰テスト：[Yes/No/N/A] - [説明]

追加を推奨するテスト

1. [追加すべき具体的なテストケース]
2. [別のテストケース]

---

❓ 質問と不確かな点

確信が持てず、確認したい点：

1. [設計上の判断についての質問]

   • 背景：[質問する理由]
   • 想定：[回答についての推測]

2. [エッジケースについての質問]

   • 背景：[これが重要な理由]
   • 潜在的な問題：[起こりうる問題]

---

✅ レビュー判定

項目	状態	備考
コード品質	🟢/🟡/🔴	[簡単なコメント]
セキュリティ	🟢/🟡/🔴	[簡単なコメント]
パフォーマンス	🟢/🟡/🔴	[簡単なコメント]
テストカバレッジ	🟢/🟡/🔴	[簡単なコメント]
ドキュメント	🟢/🟡/🔴	[簡単なコメント]

総合判定：[APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]

---

レビューチェックリスト（内部用 - 分析に使用）

コード品質

• コードの重複がない
• 関数が単一の役割に集中し、簡潔である
• 変数名・関数名が明確である
• デッドコードやコメントアウトされたコードがない
• 適切にエラーを処理している
• 設定可能にすべき値がハードコードされていない

セキュリティ

• コードにシークレットや認証情報が含まれていない
• 必要な箇所で入力値を検証している
• SQL インジェクションの脆弱性がない
• XSS の脆弱性がない
• 認証・認可チェックが実装されている
• 機密データが適切に扱われている

パフォーマンス

• N+1 クエリのパターンがない
• 不要な再レンダリングがない（React）
• メモリリークがない
• 効率的なアルゴリズムを使用している
• 非同期コンテキストでブロッキング処理がない

破壊的変更

• API コントラクトが維持されている（変更した場合は文書化されている）
• データベースのマイグレーションを元に戻せる
• リスクの高い変更にはフィーチャーフラグがある
• 後方互換性が維持されている

ドキュメント

• 公開 API が文書化されている
• 複雑なロジックにコメントがある
• 必要に応じて README が更新されている
• ユーザー向けの変更がある場合、CHANGELOG に記載されている

重要な注意事項

1. 具体的にする：常に正確なファイルパスと行番号を示してください
2. 建設的にする：問題を指摘するだけでなく、修正案を提案してください
3. 優先順位をつける：重大な問題を先に、細かな指摘を後にしてください
4. 文脈を考慮する：コードベースに既存のパターンがあれば考慮してください
5. 質問する：不確かな場合は、推測せずに質問してください