PR 作成スキル

現在の変更から GitHub Pull Request を作成する。未コミットの変更がある場合は git-commit スキルを使ってコミットしてから PR を作成する。

前提条件

• gh CLI が認証済みであること

手順

1. 現状の確認

以下を並列で実行して状況を把握する:

git status
git log --oneline -10
git branch -vv

2. コミットされていない変更の処理

未コミットの変更や未追跡のファイルがある場合は、git-commit スキル (/git-commit) を使ってコミットする。git-commit スキルがブランチの作成やコミットメッセージの作成を担当する。コミットメッセージは git-commit スキルのルールに従い、-m 引数内で \n を使って擬似改行を表現してはいけない。

注意: /git-commit は内部で /ensure-branch を呼ぶため、Step 2 を実行した場合は Step 3 をスキップしてよい。

重要: git-commit スキルが完了したら、必ず Step 4 に進むこと。ここで処理を止めないこと。

3. ブランチの確認（Step 2 を実行しなかった場合のみ）

未コミットの変更がなく Step 2 をスキップした場合のみ、/ensure-branch スキルを使って作業ブランチが適切かどうかを確認・切り替える。ensure-branch は main や develop などのデフォルトブランチにいる場合に、作業用ブランチへの切り替えをユーザーと確認しながら行うスキルである。

重要: ブランチの確認・切り替えが完了したら、必ず Step 4 に進むこと。ここで処理を止めないこと。

4. 差分の分析

メインブランチからの全変更を確認する:

git log main..HEAD --oneline
git diff main...HEAD --stat

すべてのコミット を確認すること。最新コミットだけでなく、PR に含まれる全コミットの内容を把握してからタイトルと本文を作成する。

git log main..HEAD の出力が空（コミットなし）の場合は、PR にする変更がない可能性がある。ユーザーに「何を PR にしたいか」を確認してから Step 5 以降に進むこと。

5. 関連 issue の特定

以下のいずれかから、この PR に対応する issue 番号が読み取れないか確認する:

• ブランチ名（例: fix/123-xxx, 123-something のように issue 番号を含む場合）
• git log main..HEAD のコミットメッセージ中の #123 のような issue 参照
• これまでの会話でユーザーから伝えられた issue 番号

候補が見つかった場合は gh issue view <number> で内容を確認し、実際にこの変更が解決する issue かどうかを確かめる。曖昧な場合は推測で決めず、ユーザーに確認する。

対応する issue がない場合、このステップは省略してよい。

6. PR タイトルと本文の作成

タイトル

• 70文字以内で簡潔に
• 変更の目的がわかるように書く
• 詳細はタイトルではなく本文に書く

本文のテンプレート

## 概要
<!-- 変更の目的、何をどう変えたか、影響範囲を箇条書き 1〜3 点 -->

<!-- 対応する issue がある場合のみ -->
Closes #<issue番号>

## 確認事項
<!-- 実際に確認した内容と結果を書く。未確認なら理由を書く。必要ならレビュアーに見てほしい観点も書く -->

## 補足
<!-- 既知の制約、残課題、後続対応があれば書く。なければ省略可 -->

🤖 Generated with <現在使用中の AI Agent 名>

本文の書き方のルール

• ## 概要 には「なぜこの変更が必要か」「何を変えたか」「影響範囲」を優先して書く
• ## 確認事項 には、実際に行った確認と結果を書く
• コマンド名だけを書かず、その確認で何が分かったかまで書く
• 検証を実施していない場合は、未確認であることと理由を書く
• 設定変更や文言修正などで追加検証が不要な場合は、その判断理由を書いてよい
• レビュアーに重点的に見てほしい観点や残るリスクがあれば ## 確認事項 または ## 補足 に書く
• ## 補足 は情報がない場合は省略してよい
• 実施予定だけのチェックリストや、意味の薄い形式的なテスト計画は書かない

関連 issue の記載ルール

• Step 5 で対応する issue が特定できた場合、## 概要 に Closes #<issue番号> を書く
• Closes キーワードは GitHub がマージ時に issue を自動で close する仕組みのため、必ずこの単語を使う
• 対応する issue がない場合は、この行自体を書かない

生成元表記のルール

• PR 本文の最後には、🤖 Generated with <現在使用中の AI Agent 名> を記載する
• AI Agent 名は、このスキルを実行しているエージェント自身の正式名称をそのまま使う
• Codex なら Codex、Claude Code なら Claude Code、その他の AI Agent ならその名称を使う
• エージェント名が特定できない場合は推測で特定の製品名を書かないこと
• Claude Code でないのに Claude Code と書かないこと
• リンクは付けず、プレーンテキストで統一する

7. push と PR 作成

# リモートに push（未 push の場合）
git push -u origin HEAD

# PR 作成（本文は HEREDOC で渡す）
gh pr create --title "タイトル" --body "$(cat <<'EOF'
## 概要
- ...

Closes #123

## 確認事項
- 関連するテストまたは検証を実施し、期待した結果を確認
- 未確認の項目があれば、理由とレビューで見てほしい観点を明記

## 補足
- 既知の制約、残課題、後続対応があれば記載

🤖 Generated with <現在使用中の AI Agent 名>
EOF
)"

対応する issue がない場合は Closes #123 の行を省く。

8. 完了報告

作成した PR の URL をユーザーに伝える。