mcpField
G
gh-pr-review

gh-pr-review

github.com/dzhuneytテスト・品質057 回インストール2 週間前に更新
リポジトリ

gh-pr-review について

gh-pr-review は、GitHub CLI で変更内容、チェック、コードの背景を調べ、コマンドやテストで指摘を検証する構造化されたプルリクエストレビュー用スキルです。根拠に基づくフィードバックと明確な判断を必要とするレビュアー向けです。

主な機能

  1. 01PR の詳細、レビュー、チェックを取得
  2. 02差分と変更ファイルの背景を確認
  3. 03関連テストを実行して主張を検証
  4. 04セキュリティ、品質、完全性を評価
  5. 05指摘事項と総合判断を提示

活用シーン

  1. 01マージ前のプルリクエストレビュー
  2. 02失敗または古い CI チェックの調査
  3. 03不足しているテストやドキュメントの特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dzhuneyt/skills --skill gh-pr-review

インストール後、Claude Code で/gh-pr-reviewを入力して読み込まれたか確認します。

詳細

プルリクエストのレビューを支援してください。詳細かつ構造化されたレビューを提示してください。

レビュー対象の PR： $ARGUMENTS

レビュー手順：

  1. GitHub CLI を使って PR の詳細を取得する
  2. 既存のレビューコメントとステータスチェックを確認する
  3. チェックに失敗している場合は、失敗の詳細を調べて修正案を提示する
  4. どの CI/CD チェックが設定されているかを分析し、重要なチェックが欠けているようなら警告する
  5. 差分のコード変更を分析する
  6. 変更されたファイルを読み、差分以外の背景を理解する
  7. 記述するすべての指摘を検証する：
    • ブランチをチェックアウトし、PR が影響するテストを実行する。予想ではなく実際の出力を報告する。
    • マージ状態と CI が実行されたかどうかを確認する。最後の push より前の成功チェックは古いものです。
    • 読み取るだけでは確証が得られない指摘については、確認用の使い捨てテストを作成して実行し、その後削除する。
  8. 実施されるべきだった変更のうち、欠けているものを特定する：
    • ロジックの不足：更新されるべき関連コードが更新されていない
    • ドキュメントの不足：「なぜ」を説明するコードコメント（特に自明でない判断に関するもの）、README の更新、更新が必要な API ドキュメント
    • テストの不足：新機能に必要なテストケース
  9. 以下を含む構造化されたフィードバックを提示する：
    • コード品質：ロジック、読みやすさ、保守性
    • セキュリティ：潜在的な脆弱性やセキュリティ上の懸念
    • パフォーマンス：効率性や最適化の機会
    • テスト：テストカバレッジと品質
    • ドキュメント：「なぜ」を説明するコードコメント（重要なロジックを重点的に）、ドキュメントの更新
    • アーキテクチャ：設計上の判断とパターン
    • 依存関係：新しい依存関係とその妥当性
    • CI/CD カバレッジ：この種の変更に対して設定すべきチェックの不足
    • 完全性：追加すべきだったのに欠けているもの

各項目について、以下を提示してください：

  • ✅ 問題がなさそうな点
  • ⚠️ 改善すべき点
  • 🔴 重大な問題（該当する場合）

すべての指摘に根拠を示してください。

コードの説明だけでは指摘として不十分です。各指摘には次の3つの要素を含めてください：

  1. 仕組み — すべての主張に file:line を示し、作者が該当箇所にすぐ移動できるようにする。
  2. 根拠 — コマンド出力、テスト結果、実行した調査結果を示す。推測を事実のように提示しない。検証できていない点があれば、その旨を明記し、何を確認すれば確定できるかを述べる。
  3. 問題発生までの流れ — 同じ不具合を読む側の視点で説明する。誰が操作していて、どの画面を開き、何を入力し、何が表示され、実際には何が起きるのかを明示する。問題が発生した時点で説明を止める。

順序は内容と同じくらい重要です。まず、通常はコードの数行、テスト、実際のコマンド出力など、指摘を裏付けるものを示してください。根拠の後に議論を続けます。最初に証拠を示せば、読者はその後の説明を検討できます。先に議論を示すと、読者はその間ずっと、それを信じてよいか判断することになります。

指摘がドメインの概念に基づく場合は、その概念を先に、3行または小さな表で説明してください。前提となるモデルを知らないレビュー担当者でも、指摘を評価できるようにします。

根拠を示せない指摘は除外してください。欠陥のように読める推測は、何も言わないより作者の時間を浪費します。

指摘はそれぞれ短くし、互いに分けてください。

指摘1件につきレビューコメント1件としてください。ひとつの本文に複数の指摘をまとめないでください。読者がそれぞれを個別に受け入れるか判断できるよう、指摘は分けて提示してください。

各コメントは、根拠、影響、修正案の順に構成してください。

各コメントは最大3段落、文章部分で500語以内を目安にしてください。コードブロックは語数に含みません。短くすると要点が失われる場合に限り、制限を超えてかまいません。気に入っている指摘を残すために制限を超えないでください。

段落を読んでも作者が次に取る行動が変わらないなら、その段落は削除してください。

最後に総合評価を記載してください： APPROVE、REQUEST CHANGES、または COMMENT PR 番号または URL が指定されていない場合： 現在のブランチに対応する PR を探します。main ブランチにいる場合は、オープン中の PR を一覧表示し、どれをレビューするか尋ねます。

次の GitHub CLI コマンドを使用します。

  • gh pr view - PR の詳細、レビュー、ステータスチェックを取得します
  • gh pr diff - コードの変更を取得します
  • gh pr checks - チェックの詳細なステータスと失敗ログを取得します
  • gh run view - チェックが失敗している場合、ワークフローの実行詳細を取得します
  • .github/workflows/ を確認し、どの CI/CD チェックが設定されているか把握します

コメント

Markdown 対応