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: コードレビュー観点 以下の観点からコードをレビューする。 ### 2.1 セキュリティ 入力検証、インジェクション（SQL / XSS / コマンド / パス）、認証・認可、機密情報の取り扱い。 ### 2.2 パフォーマンス N+1 クエリ、不要なループ・計算、メモリ効率、非同期処理の使い方。 ### 2.3 可読性・保守性 命名の一貫性、責務分離、コメント（Why）、コードの重複。 ### 2.4 エラーハンドリング 例外処理の粒度、例外の握りつぶし、エラーメッセージ、リソースのクリーンアップ。 ### 2.5 テスト 変更部分のカバレッジ、エッジケース、テストの独立性・可読性。 ### 2.6 言語・フレームワーク固有のベストプラクティス 言語イディオム、フレームワーク規約、型安全性。該当言語の `python-dev` / `go-dev` / `typescript-dev` 等のスキルがあればその規約に従う。 ### 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 営業日内応答を目安にする。1000 行超や複数目的混在の PR は分割依頼を優先する。 - **Comments**: