pr-code-reviewlisted

# PR Code Review GitHubのPull Requestに対して包括的なコードレビューを実施し、レビュー結果をマークダウンファイルとして出力するスキル。 ## ワークフロー概要 1. **PR情報の取得**: ghコマンドでPRの詳細とdiffを取得 2. **コード分析**: 複数の観点からコードを分析 3. **レビュー作成**: 構造化されたレビューレポートを生成 4. **ファイル出力**: レビュー結果をマークダウンファイルとして保存 ## Step 1: PR情報の取得 PR URLまたはPR番号から情報を取得する。 ```bash # PR詳細の取得 gh pr view <PR番号> --repo <owner/repo> # PRのdiffを取得 gh pr diff <PR番号> --repo <owner/repo> # PRのファイル一覧を取得 gh pr view <PR番号> --repo <owner/repo> --json files ``` **ユーザーがPR URLを指定した場合:** URLから`owner/repo`と`PR番号`を抽出する（例: `https://github.com/owner/repo/pull/123`）。 **ユーザーがPR番号のみを指定した場合:** 現在のディレクトリのリモートリポジトリを使用するか、リポジトリ名を確認する。 ## Step 2: コードレビュー観点 以下の観点からコードをレビューする。詳細は[references/review-guidelines.md](references/review-guidelines.md)を参照。 ### 2.1 セキュリティ - 入力値バリデーション - インジェクション脆弱性（SQL、XSS、コマンド） - 認証・認可の実装 - 機密情報の取り扱い ### 2.2 パフォーマンス - N+1クエリ問題 - 不要なループや計算 - メモリ効率 - 非同期処理の適切な使用 ### 2.3 可読性・保守性 - 命名規則の一貫性 - 関数・クラスの責務分離 - コメントの適切さ - コードの重複 ### 2.4 エラーハンドリング - 例外処理の適切さ - エラーメッセージの明確さ - リソースのクリーンアップ ### 2.5 テスト - テストカバレッジ - エッジケースの考慮 - テストの可読性 ### 2.6 言語・フレームワーク固有のベストプラクティス - 言語のイディオム - フレームワークの規約 - 型安全性 ### 2.7 エンジニアリング作法（eng-practices） `eng-practices` スキルが扱う共通レビュー観点を併用する。Google eng-practices の Reviewer Guide 由来。 - **Standard**: 「現状より明確に良くなるか」で承認可否を判断する。完璧でなくても健全性が前進していれば承認し、残りは新 CL/issue に切る。 - **What to Look For**: 設計 / 機能 / 複雑性 / テスト / 命名 / コメント(Why) / ドキュメント / 文脈 の 8 観点を 2.1〜2.6 と直交させて確認する。 - **Navigate**: PR 説明 → 主ロジック → テスト の順で読み、大きな設計問題は細部コメントより先に出す。 - **Speed**: 1 営業日内応答を