PR作成スキル
現在のブランチの変更内容を分析し、PRを作成する。
ルール
- •PRは
ippei-shimizu/buzzbaseリポジトリに作成する - •ベースブランチはデフォルトで
stg($ARGUMENTSで指定があればそちらを使用) - •すべて日本語で記述する
- •作成前に必ずユーザーの承認を得る
- •リモートにプッシュされていない場合は先にプッシュする
ワークフロー
1. 現在のブランチ状態を確認
bash
# 現在のブランチ名 git branch --show-current # 未コミットの変更がないか確認 git status --short # リモートとの同期状態を確認 git log origin/$(git branch --show-current)..HEAD --oneline 2>/dev/null # ベースブランチからの全コミット git log stg..HEAD --oneline # ベースブランチからの全差分 git diff stg...HEAD --stat
未コミットの変更がある場合はユーザーに通知し、先にコミットするか確認する。
2. 差分の分析
ベースブランチからの全コミットと差分を分析する:
bash
# コミットメッセージ一覧 git log stg..HEAD --format="%s" # 変更ファイル一覧 git diff stg...HEAD --stat # 詳細な差分(大きい場合はサブエージェントで分析) git diff stg...HEAD
以下を把握する:
- •変更されたファイルとその種類(新規/変更/削除)
- •実装の目的と内容
- •影響範囲(front / back / 両方 / その他)
- •関連するissue番号(ブランチ名やコミットメッセージから推測)
3. PRタイトルの生成
- •コミット履歴と差分から変更の主目的を要約する
- •70文字以内の簡潔な日本語タイトル
- •
$ARGUMENTSにタイトルのヒントがあればそれを優先する
4. PR descriptionの生成
/pr-description スキルと同じテンプレートに沿って生成する:
markdown
## issue close #ISSUE_NUMBER ## 実装概要 <!-- 何をしたかを簡潔に(1-3行) --> ## 背景 <!-- なぜこの変更が必要だったか --> ## やらなかったこと <!-- スコープ外にしたこと。なければ「特になし」 --> ## 受入基準 <!-- この PR がマージ可能と判断するための条件をチェックリストで --> - [ ] 基準1 - [ ] 基準2 ## 実装詳細 <!-- 技術的な実装内容。ファイル単位やモジュール単位で説明 --> ## スクリーンショット <!-- UI変更がある場合のみ。なければ「なし」 --> ## 確認手順 <!-- レビュワーが動作確認するための具体的な手順 --> 1. 手順1 2. 手順2 ## 影響範囲 <!-- この変更が影響する画面・機能・モジュール --> ## コード上の懸念点 <!-- レビュワーに特に見てほしい箇所や、判断に迷った実装 --> ## その他 <!-- 補足情報。なければ「特になし」 -->
5. ユーザーに確認
作成内容を以下のフォーマットでプレビュー表示し、承認を待つ:
code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PR プレビュー ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ブランチ: <head-branch> → <base-branch> タイトル: <タイトル> 本文: <description プレビュー> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ユーザーの明示的な承認(「OK」「作成して」等)を待つ。承認前にPRを作成してはならない。 フィードバックがあれば修正して再度プレビューを表示する。
6. プッシュとPR作成
承認後、以下の順序で実行する:
bash
# リモートにプッシュされていない場合 git push -u origin $(git branch --show-current) # PR作成 gh pr create \ --repo ippei-shimizu/buzzbase \ --base stg \ --title "<タイトル>" \ --body "$(cat <<'EOF' <description内容> EOF )"
7. 結果報告
作成されたPRのURLを表示する。
注意事項
- •ユーザーの承認なしにPRを作成しない
- •ユーザーの承認なしに
git pushしない - •差分から読み取れる事実に基づいて記述し、推測が入る箇所は明示する
- •issue番号がブランチ名やコミットから特定できない場合は
close #の行は空欄にする(推測で番号を入れない) - •
$ARGUMENTSが指定された場合、それをPRの背景コンテキストとして活用する - •会話の文脈(直前の実装作業など)がある場合は、それを活用してdescriptionを充実させる