Explain This PR（このPRを説明する）
GitHubのプルリクエストを読み取り、その変更内容を理解し、平易な英語で説明します。PRコメントとして投稿することで、レビュアーがすぐにコンテキストを把握できます。
ステップ1: セットアップの確認
gh が認証済みであることを確認します:
git auth status
認証されていない場合: git auth login を実行し、プロンプトに従います。
入力を確認します。ユーザーは以下のいずれかを提供する必要があります:
- GitHub PR URL（例:
https://github.com/owner/repo/pull/123） - 現在のリポジトリのPR番号（例:
#123） - キーワード「current」（現在のブランチのPRを使用する場合）
入力がない場合、「どのPRを説明しますか？URL、PR番号、またはアクティブブランチの場合は 'current' と入力してください。」と尋ねます。
ステップ2: PRコンテキストの取得
PRメタデータを取得:
git pr view PR_URL_OR_NUMBER --json number,url,title,body,author,baseRefName,headRefName,additions,deletions,changedFiles,commits,labels,state,isDraft
isDraft が true の場合、ユーザーに次のように注意します:「このPRはドラフトです。説明は現在の状態に基づいています。」
差分を取得:
git pr diff PR_URL_OR_NUMBER
差分が400行を超える場合は、--stat サマリーと差分の最初の200行を読み取ります:
git pr view PR_URL_OR_NUMBER --json files
git pr diff PR_URL_OR_NUMBER | head -200
既存のコメントを取得（重複を避けるため）:
git pr view PR_URL_OR_NUMBER --json comments --jq '.comments[].body' 2>/dev/null | head -20
ステップ3: 説明を書く
2段落で書きます。各ルールを読んでから書き始めてください。
段落1: 何をするか（技術的）
- 主要な変更ごとに1文
- 変更された特定のファイル、関数、またはシステムに名前を付ける
- 差分が明確な場合はbefore/afterを述べる
- 差分に具体的な数値があれば含める（削除された行数、削除されたテーブル、追加されたエンドポイントなど）
- 能動態、現在形
例:
auth.middleware.tsのインメモリセッションキャッシュをRedisバックアップのキャッシュ（src/cache/redis.ts）に置き換えます。新しいRedisモジュールにget、set、invalidateメソッドを追加し、UserService.getById()を5分TTLでラップします。単一プロセスに制限され、複数インスタンス間でセッションのずれを引き起こしていたMapベースのキャッシュを削除します。
段落2: なぜ重要か（ビジネス/プロダクトへの影響）
- 誰がどのように恩恵を受けるか
- この変更が解決する問題、または軽減するリスク
- コミットメッセージに「なぜ」が含まれている場合は、そのコンテキストを使用する
- 差分やコミットに明確な「なぜ」がない場合は、推測せずにこの段落を省略する
例:
負荷がかかった状態で /api/me エンドポイントにアクセスしたユーザーが、サーバーインスタンス間で一貫性のないセッションデータを受け取り、断続的に401エラーが発生していました。この変更により、すべてのインスタンスでセッション状態が一貫し、認証されたリクエストごとに1回のデータベースクエリが不要になるため、データベースへの負荷が軽減されます。
両段落に共通するルール:
- ダッシュ（—）は使用しない。代わりにカンマまたはピリオドを使用する
- 不要な言葉は使わない：「このPRは」「この変更は」「ご覧のとおり」
- 結果を創作しない。差分またはコミットメッセージに直接見られる影響のみを述べる
- PRが動作変更のない純粋なリファクタリングである場合は、明示的に次のように述べる：「観測可能な動作の変更なしにXをYにリファクタリングします。」
- 合計150語以内
ステップ4: 自己QA
投稿前に確認:
- 段落1で差分から特定のファイルまたは関数に名前を付けている
- メトリクスや結果を創作していない
- ダッシュ（—）を使用していない
- 不要なフレーズを使用していない
- 合計150語以内
- 明確な「なぜ」が存在しない場合、推測せずに段落2を省略している
違反があれば投稿前に修正します。
ステップ5: PRコメントとして投稿
説明をユーザーに提示します。「この説明をPRコメントとして投稿しますか、それとも先に編集しますか？」と尋ねます。
確認が得られたら、バッククォート、引用符、改行を安全に処理するために、ボディを標準入力から渡します:
gh pr comment PR_URL_OR_NUMBER --body-file - << 'EOF'
説明内容をここに記述
EOF
投稿後:「コメントを追加しました。閲覧はこちら: [ステップ2のURL]」
ユーザーが「出力のみ」と言った場合は、手動でコピー＆ペーストできるように、説明をコードブロック内に表示して投稿しません。