backend-pr-describer

name	backend-pr-describer
description	コミット履歴と差分から質の高い Pull Request 説明文を生成する。Summary / Changes / Test plan / Risk を構造化し、レビュアーが 30 秒で理解できる PR を作る。「PR 説明書いて」「PR description 作って」「pull request の本文を整えて」などで起動。

PR Describer

ブランチのコミット履歴と diff から、レビュアーフレンドリーな PR 説明文を生成する。

いつ使うか

• ブランチの作業が完了し、PR を開く直前
• 既存 PR の説明が不十分で書き直したいとき

実行手順

1. ベースブランチを特定

git remote show origin | grep "HEAD branch"   # 主流ブランチ
# または明示的に: main / master / develop / trunk

ユーザーから指定があればそれを使う。なければ確認する。

2. 差分情報を収集

以下を並列で取得:

git log <base>..HEAD --oneline          # コミット一覧
git log <base>..HEAD --stat             # ファイル別変更量
git diff <base>...HEAD                  # 全差分（大きい場合は要約のみ）
git diff <base>...HEAD --name-status    # 追加/変更/削除の分類

差分が大きい（> 1000 行）場合は、代表的なファイルだけ読む。

3. 構造を決める

以下のテンプレートで出力（英語/日本語は既存 PR に合わせる。不明なら日本語）:

## Summary

<1-3 行で「何を」「なぜ」。「どう」は Changes に書く>

## Changes

- <変更点 1>
- <変更点 2>
- ...

## Test plan

- [ ] <手動/自動テスト項目 1>
- [ ] <手動/自動テスト項目 2>

## Risk / Notes

<ロールバック時の注意、既知の限界、フォローアップタスクなど。なければ省略>

4. 内容の質的要件

Summary

• WHY を最初に。「〇〇のため、△△を実装した」
• ユーザー視点（プロダクト的な価値）があればそれを、なければ技術的動機
• 課題 ID（JIRA-123, #456）があれば末尾に添える

Changes

• 実装詳細ではなく レビュアーが追うべき塊 を列挙
• ファイル名の列挙は避ける（diff を見ればわかる）
• 動詞で始める（「〇〇を追加」「〇〇を削除」「〇〇を抽出」）

Test plan

• レビュアーが動作確認に使えるチェックリスト
• 自動テストを書いた場合: 「make test を実行」で十分
• UI/API 変更がある場合: 具体的な確認手順を書く

Risk / Notes

• スキーマ変更・破壊的変更・Feature flag の有無
• 後続 PR が必要な場合はそれも記載
• 何もない PR では このセクションを省略 する（空の「特になし」は書かない）

5. コミット数との整合性

• 10 コミット以上あり、かつ PR が分割されていないなら、Changes セクションの粒度 をコミットと揃えると読みやすい
• 逆に 1-2 コミットの PR では Changes を詳細化しすぎない

6. 出力の確認

生成した説明文をユーザーに提示し、gh pr create の実行は ユーザーの明示的な指示を待つ。

勝手に PR を作らない。説明文だけ生成する。

やらないこと

• 推測や脚色で「リスク」を捏造しない。本当にリスクがなければ省略する
• diff にない変更を書かない
• 過剰な絵文字・装飾（プロジェクトの慣習に従う）
• 「このコミットでは ...」のようにコミット単位の説明を列挙する（それは commit message の役割）

出力例

## Summary

ユーザー検索が 2 秒以上かかっていた問題に対して、検索時の N+1 クエリを解消し、平均応答を 200ms に短縮した。

## Changes

- `UserRepository.FindByEmail` を preload 対応に変更
- 検索結果のレスポンス組み立てを一括取得方式にリファクタ
- ベンチマーク `BenchmarkUserSearch` を追加

## Test plan

- [ ] `go test ./internal/user/...` が通る
- [ ] `go test -bench .` で 200ms 以下を確認
- [ ] ステージングで検索 UI の体感速度を確認

## Risk / Notes

- preload 対象のテーブルが増えるためメモリ使用量が若干増加する可能性あり。ベンチマークでは問題なしを確認済み。