菜单
コミット履歴と差分から質の高い Pull Request 説明文を生成する。Summary / Changes / Test plan / Risk を構造化し、レビュアーが 30 秒で理解できる PR を作る。「PR 説明書いて」「PR description 作って」「pull request の本文を整えて」などで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。
| name | backend-pr-describer |
| description | コミット履歴と差分から質の高い Pull Request 説明文を生成する。Summary / Changes / Test plan / Risk を構造化し、レビュアーが 30 秒で理解できる PR を作る。「PR 説明書いて」「PR description 作って」「pull request の本文を整えて」などで起動。 |
ブランチのコミット履歴と diff から、レビュアーフレンドリーな PR 説明文を生成する。
git remote show origin | grep "HEAD branch" # 主流ブランチ
# または明示的に: main / master / develop / trunk
ユーザーから指定があればそれを使う。なければ確認する。
以下を並列で取得:
git log <base>..HEAD --oneline # コミット一覧
git log <base>..HEAD --stat # ファイル別変更量
git diff <base>...HEAD # 全差分（大きい場合は要約のみ）
git diff <base>...HEAD --name-status # 追加/変更/削除の分類
差分が大きい（> 1000 行）場合は、代表的なファイルだけ読む。
以下のテンプレートで出力（英語/日本語は既存 PR に合わせる。不明なら日本語）:
## Summary
<1-3 行で「何を」「なぜ」。「どう」は Changes に書く>
## Changes
- <変更点 1>
- <変更点 2>
- ...
## Test plan
- [ ] <手動/自動テスト項目 1>
- [ ] <手動/自動テスト項目 2>
## Risk / Notes
<ロールバック時の注意、既知の限界、フォローアップタスクなど。なければ省略>
make test を実行」で十分生成した説明文をユーザーに提示し、gh pr create の実行は ユーザーの明示的な指示を待つ。
勝手に PR を作らない。説明文だけ生成する。
## Summary
ユーザー検索が 2 秒以上かかっていた問題に対して、検索時の N+1 クエリを解消し、平均応答を 200ms に短縮した。
## Changes
- `UserRepository.FindByEmail` を preload 対応に変更
- 検索結果のレスポンス組み立てを一括取得方式にリファクタ
- ベンチマーク `BenchmarkUserSearch` を追加
## Test plan
- [ ] `go test ./internal/user/...` が通る
- [ ] `go test -bench .` で 200ms 以下を確認
- [ ] ステージングで検索 UI の体感速度を確認
## Risk / Notes
- preload 対象のテーブルが増えるためメモリ使用量が若干増加する可能性あり。ベンチマークでは問題なしを確認済み。