はじめに
今回はGitHubを用いて開発を行なっている際の、「プルリクエスト作成のフロー」を自動化するSkillを紹介いたします。
・変更差分から最適なプルリクエスト内容を自動生成
・自動でプルリクエスト作成（Draft）
までを自動化できるので、よかったらぜひコピペして使ってみてください。
過去に作成した以下のSkillと組み合わせて使うのがおすすめです。
リクエスト内容
今回は具体的な要望を一切入力することなく、Claude Codeが過去に作成したSkillなどの関連性を学習し、求めていた「プルリク作成の自動化Skill」を提案してくれました。
完成したのがこちら
一部マークダウンの仕様上、[```]の前に#を入れています。
~.claude/skills/draft-pr/SKILL.md
---
name: draft-pr
description: 現在のgitブランチのコミット履歴と差分を分析し、Conventional Commits準拠の日本語タイトル + コミット履歴から動的に組み立てた日本語説明文を生成して、ユーザー承認の上で `gh pr create --draft` でドラフトPullRequestを作成するスキル。ユーザーが `/draft-pr` と入力したとき、または「PR作って」「プルリク作って」「draft PR作って」「PR説明文書いて」「PRの説明文を生成して」「このブランチでPR出したい」など、現在のブランチからGitHub上にPullRequestを作成・準備したい場面で必ず使用する。Conventional Commits準拠のPRタイトル、コミット履歴に応じた構成のPR説明文、ベースブランチ自動検出、push未済時の確認、リポジトリのPRテンプレート尊重が必要なすべてのケースで本スキルを優先的に呼び出すこと。デフォルトはdraft PRとして作成する。
---
# draft-pr
現在のgitブランチからGitHub上にPullRequestを作成するスキル。コミット履歴と差分を読み解いて、Conventional Commits準拠の日本語タイトルと、変更内容に応じて構成を組み立てた日本語の説明文を生成し、ユーザー承認を得てから `gh pr create --draft` でドラフトPRとして作成する。
## このスキルが目指すこと
PR作成は、レビュアーへの「これは何の変更で、なぜ必要で、何を見れば良いか」というプレゼンテーションである。雑にタイトル1行 + 「変更しました」だけのPRは、レビュー負荷を上げ、後から履歴を辿るときの貴重な文脈を失わせる。本スキルの役割は次の通り:
1. ベースブランチを自動検出し、ユーザー確認を経て確定する
2. 必要に応じてリモートへのpushを行う(未pushなら必ずユーザーに確認)
3. ベースブランチからの全コミット履歴と差分を読み解き、変更の主目的・影響範囲・テスト方針を把握する
4. Conventional Commits準拠の日本語タイトルと、変更内容に応じた日本語説明文を生成する
5. ユーザー承認を得てから `gh pr create --draft` でドラフトPRを作成する
6. 作成後はPRのURLを表示するに留める(merge等の追加操作は行わない)
ユーザーが目指すゴールは「レビュアーが説明文を読むだけで変更の全体像を把握でき、効率的にレビューに入れるPR」である。スキルはそのための補助に徹する。
## 実行手順
### Step 1: 環境と前提の一括取得
以下を **並列で** 実行する:
#```bash
git branch --show-current
#```
#```bash
git remote -v
#```
#```bash
git status --short
#```
#```bash
git log --oneline -20
#```
#```bash
gh auth status
#```
#```bash
ls .github/PULL_REQUEST_TEMPLATE.md .github/pull_request_template.md 2>/dev/null
#```
これで「現在のブランチ / リモート設定 / 作業ツリー状態 / 直近の履歴 / gh CLI認証状態 / リポジトリ独自のPRテンプレートの有無」が一度に揃う。
#### 致命的な前提が満たされない場合
- `gh auth status` が認証エラー → 「`gh auth login` で認証してから再度実行してください」と伝えて終了。
- リモートが未設定(`git remote -v` が空) → 「GitHubリモートが設定されていません」と伝えて終了。
- `git branch --show-current` がmain/masterなどのデフォルトブランチを指している → 「現在main(またはmaster)上にいます。PRはfeatureブランチから出してください」と伝えて終了。
### Step 2: ベースブランチの自動検出と確認
ベースブランチの候補を以下の優先順位で自動検出する:
1. `gh repo view --json defaultBranchRef --jq .defaultBranchRef.name` で取得できるGitHubリポジトリのデフォルトブランチ
2. `git symbolic-ref refs/remotes/origin/HEAD` から取得できる `origin/HEAD` の指す先
3. `main` が `git branch -a` に存在すれば `main`
4. `master` が `git branch -a` に存在すれば `master`
検出結果をユーザーに提示し、確認を取る:
#```
## ベースブランチの自動検出
検出したベースブランチ: `main`
(GitHubリポジトリのデフォルトブランチとして設定されています)
このブランチをベースとしてPRを作成します。問題ありませんか?
別のブランチをベースにしたい場合は指定してください。
#```
ユーザーがOKを出すか別ブランチを指定するまで待つ。
### Step 3: 未コミット変更とpush状態の確認
#### 未コミット変更がある場合
`git status --short` で出力がある場合、コミットされていない変更があるということ。以下を伝える:
#```
## 未コミットの変更があります
以下のファイルに未コミットの変更があります:
- `path/to/file1.ts`
- `path/to/file2.ts`
これらをPRに含めるには、先にコミットが必要です。`/auto-commit` スキルで分割コミットしてから本スキルを再実行することをお勧めします。
このまま現在のコミット済み内容のみでPRを作成しますか? それとも一旦中断してコミットを行いますか?
#```
ユーザーが「このまま進める」を選んだ場合のみStep 4へ進む。
#### push状態の確認
リモート追跡ブランチの状態を確認する:
#```bash
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
#```
このコマンドが失敗する(リモート追跡なし) または `git log @{u}..HEAD --oneline` でローカル先行コミットがある場合、リモートとの差分が存在する。
未pushの場合は **必ずユーザーに確認** する:
#```
## push状態の確認
現在のブランチ `feature/xxx` はリモートにpushされていません(または、ローカルにpush未済のコミットがあります)。
PR作成前に `git push -u origin feature/xxx` を実行する必要があります。
pushを実行してよろしいですか?
#```
ユーザーOKでpushを実行。NG であれば「pushしてから再度実行してください」と伝えて終了。
### Step 4: コミット履歴と差分の取得
ベースブランチからの差分を **並列で** 取得する:
#```bash
git log <base>..HEAD --oneline
#```
#```bash
git log <base>..HEAD --pretty=format:'%h %s%n%b%n---'
#```
#```bash
git diff <base>...HEAD --stat
#```
#```bash
git diff <base>...HEAD
#```
(`<base>` はStep 2で確定したベースブランチ名。`..` ではなく `...` を使うのは「ベースから分岐後に追加されたコミット分の差分」を見るため)
#### 差分が極端に大きい場合
`git diff <base>...HEAD` が数千行を超える場合は全文読み込みを避け、`--stat` と代表ファイルの抜粋(`git diff <base>...HEAD -- <key-files>`)で判断する。説明文に「差分が大きいため概要ベースで記述」と注記する。
### Step 5: 変更内容の分析
取得した情報から次を読み取る:
- **PRの主目的**: 何を達成するためのPRか(機能追加、バグ修正、リファクタなど)
- **コミットの粒度**: コミットがすでに論理的に分割されているか、混在しているか
- **影響範囲**: どのモジュール・ディレクトリ・機能に影響するか
- **テスト/検証**: テストファイルが追加・変更されているか、CI上で検証可能か
- **破壊的変更の有無**: API変更・スキーマ変更・依存削除などレビュアーが特に注意すべき事項
- **関連Issue**: コミットメッセージに `#数字` や `Closes #` 等の参照があるか
### Step 6: PRタイトルの生成(Conventional Commits準拠)
PRタイトルは **Conventional Commits規約** に従って生成する。書式は:
#```
<type>(<scope>): <description>
#```
#### typeの選び方
PRが含む全コミットの中で **最も主要な目的** を反映するtypeを1つ選ぶ。複数の関心事が混在する場合は最も影響が大きいものを選ぶ(例: 機能追加 + テスト追加 → `feat`)。
| type | 用途 |
|------|------|
| `feat` | 新機能の追加 |
| `fix` | バグ修正 |
| `docs` | ドキュメントのみの変更 |
| `style` | フォーマット・空白等(動作変更なし) |
| `refactor` | 動作を変えないコード整理 |
| `perf` | パフォーマンス改善 |
| `test` | テストの追加・修正 |
| `build` | ビルドシステム・依存関係の変更 |
| `ci` | CI/CD設定の変更 |
| `chore` | その他の雑務 |
#### scope と description
- **scope**: 変更モジュールが明確なら付ける(`feat(auth):` など)。横断的・複合的な場合は省略可。
- **description**: 日本語で簡潔に。**70文字以内** を目安(`gh pr create` で受け付けるが、GitHub UIで折り返されないため)。末尾に句点(。)は付けない。
- **破壊的変更**: `feat(api)!:` のように `!` を付ける。
**例**:
- `feat(auth): JWT認証を追加`
- `fix(api): ユーザー作成時のメール重複バリデーションを修正`
- `refactor(db): クエリビルダをORMから生SQLに移行`
- `docs: アーキテクチャ概要図を追加`
### Step 7: PR説明文の動的生成
固定テンプレートに当てはめるのではなく、**変更内容に応じてセクション構成を決める**。以下が判断指針:
#### リポジトリのPRテンプレートが存在する場合
`.github/PULL_REQUEST_TEMPLATE.md` または `.github/pull_request_template.md` が存在する場合は、その構造を尊重しつつ各セクションを埋める。テンプレートのチェックボックス(`- [ ]`)はユーザーが後で埋めるべきものなのでそのまま残す。
#### リポジトリのPRテンプレートが存在しない場合
以下のセクションを **変更内容に応じて取捨選択** して組み立てる(全部入れる必要はない、必要なものだけ):
- `## 概要` (常に含める): 1〜3行でPRの主目的を述べる
- `## 主な変更点` (常に含める): 箇条書きでコミットを束ねた論理的な変更点を列挙
- `## 背景・理由` (背景説明が必要な場合のみ): なぜこの変更が必要か。Issue参照がある場合はここでリンク
- `## 影響範囲` (横断的変更や破壊的変更がある場合のみ): どのモジュール・利用者に影響するか
- `## 動作確認` (テストや手動検証の手順がある場合のみ): レビュアーが確認すべき手順、追加したテスト
- `## 関連Issue / PR` (該当があれば): `Closes #123`, `Refs #456` など
- `## レビューの観点` (注目してほしい点がある場合のみ): 「特にここを見てほしい」「設計判断が分かれそうな箇所」など
セクション配下の文体:
- 箇条書きを基本とする(レビュアーの視認性のため)
- コミットメッセージの単純な羅列は避ける(コミットは `git log` で見れば良いので、PR説明文では **コミットを束ねて意味のある単位で語る**)
- ファイルパスや関数名は `` ` `` で囲む
- 専門用語が多い変更ではレビュアーへの予備知識を補足する
### Step 8: 計画をユーザーに提示する
以下のフォーマットで一括提示する:
#```
## PR作成プラン
### ベースブランチ → ヘッドブランチ
`main` ← `feature/xxx`
### コミット数: N件 / 変更ファイル数: M件 (+P -Q行)
### タイトル(案)
#```
feat(auth): JWT認証を追加
#```
### 説明文(案)
#```
## 概要
JWTベースのユーザー認証フローを実装。トークンの発行・検証・リフレッシュを `auth` モジュールに集約した。
## 主な変更点
- `src/auth/jwt.ts` にトークン発行・検証ロジックを追加
- `src/middleware/auth.ts` でリクエスト時のトークン検証を実装
- `src/routes/auth.ts` にログイン・リフレッシュエンドポイントを追加
## 動作確認
- `npm test` で `auth/jwt.test.ts` の全ケースがパス
- 手動: `POST /api/auth/login` で200応答とJWTトークンを取得できることを確認
#```
### 作成モード
**ドラフトPR** として作成します(`gh pr create --draft`)。
この内容でPRを作成してよろしいですか?
- 「OK」「はい」「進めて」 → ドラフトPRを作成
- タイトルや説明文を修正したい場合はその旨を伝えてください
- ドラフトでなくready状態で作成したい場合はその旨を伝えてください
#```
ユーザーから修正指示があれば反映する。OKが出るまで `gh pr create` は実行しない。
### Step 9: PR作成の実行
承認を得たら `gh pr create` を実行する。説明文はHEREDOCで渡す(改行・引用符を安全に扱うため):
#```bash
gh pr create --draft --base main --title "feat(auth): JWT認証を追加" --body "$(cat <<'EOF'
## 概要
JWTベースのユーザー認証フローを実装。トークンの発行・検証・リフレッシュを `auth` モジュールに集約した。
## 主な変更点
- `src/auth/jwt.ts` にトークン発行・検証ロジックを追加
- `src/middleware/auth.ts` でリクエスト時のトークン検証を実装
- `src/routes/auth.ts` にログイン・リフレッシュエンドポイントを追加
## 動作確認
- `npm test` で `auth/jwt.test.ts` の全ケースがパス
- 手動: `POST /api/auth/login` で200応答とJWTトークンを取得できることを確認
EOF
)"
#```
ユーザーが「draftではなくreadyで作成」を明示した場合のみ `--draft` を外す。それ以外はデフォルトで `--draft` を付ける(レビュアーへの不要な通知や、まだ整っていないPRがレビュー待ちに紛れ込むのを防ぐため)。
### Step 10: 完了報告
PR作成成功後、以下を出力する:
#```
## PRを作成しました
- URL: <gh pr create が返したURL>
- タイトル: feat(auth): JWT認証を追加
- ベース: main ← ヘッド: feature/xxx
- 状態: Draft
レビュー準備が整ったら、PRページで「Ready for review」をクリックしてください。
または `gh pr ready <PR番号>` で同じ操作ができます。
#```
merge・rebase・追加コミット等は本スキルでは行わない。
## エッジケース
- **同一ブランチで既にPRが存在する場合**: `gh pr list --head <branch> --json number,url,title` で確認し、既存PRがあれば「このブランチには既にPR #N が存在します。新規作成するのではなく既存PRの説明文を更新しますか?」と確認する。更新を選んだ場合は `gh pr edit <number> --title ... --body ...` を使う。
- **ベースブランチからの差分が0コミットの場合**: 「ベースブランチ `main` からの差分がありません。コミットを行ってから再度実行してください」と伝えて終了する。
- **コミットが1件しかない場合**: 既存のコミットメッセージをベースにタイトルを組み立てる。説明文は短くなりがちだが、それでも「概要」と「主な変更点」のセクションは設ける。
- **複数のtypeが混在しPRとして主目的が定まらない場合**: `mixed` のような擬似typeは使わず、最も影響が大きいtypeを選んだ上で説明文の冒頭で「このPRには複数の独立した変更が含まれます」と明記する。理想的にはユーザーに「このPRはコミットを分けて別々のPRに分割するほうが良いかもしれません。続行しますか?」と確認する。
- **gitリポジトリでない / GitHubリポジトリでない場合**: `gh repo view` が失敗するならその旨を伝え終了する。
- **ghコマンドがインストールされていない場合**: `command -v gh` で確認できない場合は「GitHub CLI (gh) のインストールが必要です。https://cli.github.com/ からインストールしてください」と伝えて終了する。
- **PRテンプレートが英語の場合**: リポジトリのテンプレートが英語で書かれていても、本スキルは日本語で説明文を生成する。ただしテンプレートの **見出しやチェックボックスのラベル** はテンプレートのまま英語で残し、各セクション内の本文を日本語で記述する。リポジトリの方針が完全英語と明らかな場合のみ「このリポジトリは英語で記述されているようですが、PR説明文も英語にしますか?」と確認する。
- **--fillオプションを使うべきか**: 使わない。`gh pr create --fill` はコミットメッセージをそのままタイトル/本文に流用するが、本スキルの価値は「コミットを束ねた意味的な説明文」を生成することにあるため、必ず明示的に `--title` と `--body` を渡す。
## 振る舞いの原則
- **承認なしに `gh pr create` を打たない**: 計画段階で必ずユーザー確認を取る。これが最重要原則。
- **デフォルトはdraft PR**: ユーザーが明示的に「readyで」と言わない限り `--draft` を付ける。レビュー負荷の不要な発生を防ぐため。
- **未pushの場合は必ず確認**: ローカルの未pushコミットがある状態で勝手にpushしない。pushはリモート状態を変える破壊的操作に近いため、ユーザー意図の確認を経る。
- **既存PRがある場合は新規作成より更新を提案**: 同じブランチに対して複数のPRを濫造しない。
- **コミット履歴をそのまま貼らない**: PR説明文は `git log` の代替ではない。コミットを束ねて意味のある単位で記述する。
- **テンプレートを尊重する**: リポジトリに `PULL_REQUEST_TEMPLATE.md` があれば、それがそのリポジトリの作法。構造を尊重した上で各セクションを埋める。
## 参考: なぜdraftをデフォルトにするか
ドラフトPRはGitHubの機能で、PRを作成しつつもレビュアーへの通知を抑え、CIは回しつつまだレビュー対象でないことを示せる仕組み。本スキルがdraftをデフォルトとする理由は次の通り:
1. **誤った早期レビュー要請を防ぐ**: スキルが自動で説明文を生成する以上、内容に齟齬がある可能性がゼロではない。ユーザーが内容を確認してから「Ready for review」に切り替えられる方が安全。
2. **CI実行の早期化**: ドラフトでもCIは回るので、レビュー前にビルド・テスト結果を得られる。
3. **Ready化は1クリック**: 後から `gh pr ready` または GitHub UI でready化するのは1操作で済むため、デフォルトdraftによる手間はほぼない。
readyで作りたい場合は、ユーザーが明示的に伝えれば `--draft` を外す。
使ってみた
mainブランチから新しいブランチdocs/initial-project-docを作成し、以下の複数ドキュメントを追加したうえでコミットまでを完了しました。
- docs/requirements.md
- docs/api.md
- docs/db.md
- docs/architecture.md
Claude Codeにて/draft-prスラッシュコマンドを実行すると、
無事に作成されました！
今回は以上になります。