mcpField
E
explain-this-pr

explain-this-pr

github.com/varnan-tech開発68747 回インストール2 週間前に更新
リポジトリ

explain-this-pr について

GitHub のプルリクエストのメタデータと差分を読み、レビュー担当者向けの平易な説明を作成するスキルです。確認後、説明を PR コメントとして投稿できます。

主な機能

  1. 01PR の詳細と差分を取得
  2. 02既存コメントを確認
  3. 03技術的な変更を説明
  4. 04根拠のある影響を記述
  5. 05承認後にコメントを投稿

活用シーン

  1. 01レビュー担当者に PR の背景を伝える
  2. 02変更ファイルや動作の概要をまとめる
  3. 03PR の議論に説明を追加

インストール

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

$npx skills add https://github.com/varnan-tech/opendirectory --skill explain-this-pr

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

同梱ファイルevals/evals.jsonREADME.md

詳細

この PR を説明する

GitHub のプルリクエストを読み、変更内容を把握して、わかりやすい英語の説明を書きます。レビュー担当者がすぐに状況を把握できるよう、PR にコメントとして投稿します。

Step 1: セットアップを確認する

gh が認証済みであることを確認します。

gh auth status

認証されていない場合は、gh auth login を実行して、プロンプトに従います。

入力を確認します。ユーザーは次のいずれかを指定する必要があります。

  • GitHub PR の URL（例：https://github.com/owner/repo/pull/123）
  • 現在のリポジトリの PR 番号（例：#123）
  • 現在のブランチの PR を使うためのキーワード「current」

入力がない場合は、「説明する PR はどれですか？ URL、PR 番号、または現在のブランチを対象にする場合は「current」と入力してください。」と尋ねます。

Step 2: PR のコンテキストを取得する

PR のメタデータを取得します。

gh pr view PR_URL_OR_NUMBER --json number,url,title,body,author,baseRefName,headRefName,additions,deletions,changedFiles,commits,labels,state,isDraft

isDraft が true の場合は、ユーザーに次のように伝えます。「この PR はまだドラフトです。説明は現在の状態に基づいています。」

差分を取得します。

gh pr diff PR_URL_OR_NUMBER

差分が 400 行を超える場合は、--stat の要約と差分の最初の 200 行を読みます。

gh pr view PR_URL_OR_NUMBER --json files
gh pr diff PR_URL_OR_NUMBER | head -200

既存のコメントを取得します（すでに書かれている内容の繰り返しを避けるため）。

gh pr view PR_URL_OR_NUMBER --json comments --jq '.comments[].body' 2>/dev/null | head -20

Step 3: 説明を書く

2 つの段落を書きます。書き始める前に各ルールを確認します。

段落 1：変更内容（技術的な説明）

  • 主な変更ごとに 1 文で説明します
  • 変更された具体的なファイル、関数、またはシステムの名前を挙げます
  • 差分から明らかな場合は、変更前と変更後を示します
  • 差分に具体的な数値が含まれている場合は記載します（削除した行数、削除したテーブル数、追加したエンドポイント数など）
  • 能動態、現在形を使います

例：

Replaces the in-memory session cache in auth.middleware.ts with a Redis-backed cache (src/cache/redis.ts). Adds get, set, and invalidate methods to the new Redis module and wraps UserService.getById() with a 5-minute TTL. Removes the Map-based cache that was limited to a single process and caused session drift across multiple instances.

段落 2：重要性（ビジネス／プロダクトへの影響）

  • 誰にどのようなメリットがあるかを説明します
  • 解決する問題、または軽減するリスクを説明します
  • コミットメッセージに「理由」が含まれている場合は、そのコンテキストを使います
  • 差分やコミットに明確な「理由」がない場合は、推測せず、この段落を省略します

例：

Users hitting the /api/me endpoint under load were getting inconsistent session data across server instances, causing intermittent 401 errors. This change makes session state consistent across all instances and reduces database load by eliminating one query per authenticated request.

両方の段落に適用されるルール：

  • エムダッシュは使わず、コンマまたはピリオドを使います
  • 埋め草の表現は使いません。「この PR」「この変更」「ご覧のとおり」など
  • 結果を捏造しません。差分またはコミットメッセージから直接確認できる影響だけを記載します
  • PR が動作変更を伴わない純粋なリファクタリングの場合は、その旨を明記します。「X を Y にリファクタリングします。観察可能な動作に変更はありません。」
  • 合計 150 語未満にします

Step 4: 自己 QA

投稿する前に、次の項目を確認します。

  • 段落 1 で、差分に含まれる具体的なファイル名または関数名を挙げている
  • 数値や成果を捏造していない
  • エムダッシュを使っていない
  • 埋め草の表現を使っていない
  • 合計 150 語未満である
  • 明確な「理由」がない場合、推測せず段落 2 を省略している

違反があれば、投稿前に修正します。

Step 5: PR コメントとして投稿する

説明をユーザーに提示します。「これを PR コメントとして投稿しますか？ それとも先に編集しますか？」と尋ねます。

確認を受けたら、バッククォート、引用符、改行を安全に扱えるよう、標準入力経由で本文を渡します。

gh pr comment PR_URL_OR_NUMBER --body-file - << 'EOF'
EXPLANATION_HERE
EOF

投稿後に「コメントを追加しました。こちらで確認できます：[Step 2 の URL]」と伝えます。

ユーザーが「output only」と指定した場合は、投稿せず、手動でコピーして貼り付けられるよう、説明をコードブロックで提示します。

コメント

Markdown 対応