| 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"
ユーザーから指定があればそれを使う。なければ確認する。
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 対象のテーブルが増えるためメモリ使用量が若干増加する可能性あり。ベンチマークでは問題なしを確認済み。
