create-pr

プルリクエストを作成する

ブランチの変更内容に基づいて、構成の整った説明を含むプルリクエストを作成します。

手順

ゲート（順番に実行）

各手順を通過するまで、下書きを作成したり gh pr create を実行したりしないでください。

1. ブランチゲート： git branch --show-current の結果がデフォルトブランチ（main、master、またはリポジトリで文書化されているデフォルトブランチ）ではありません。合格条件： ブランチ名が出力され、条件を満たしていること。
2. 根拠ゲート： まとめる対象と同じ main..HEAD（ローカルに main がない場合は origin/main..HEAD）の範囲について、コンテキストの収集に記載されたコマンドを実行済みです。合格条件： 詳細を捏造せずに、少なくとも1つのコミットの件名と変更されたファイルの領域を挙げられること。
3. テンプレートゲート： 最終的なプルリクエストのタイトルと本文に、置き換えられていないプレースホルダー（<...>、TODO、TBD）がありません。内容のない任意のセクションは、空のまま残さず削除します。合格条件： 簡単に確認し、山括弧のプレースホルダーや埋め草のトークンが見つからないこと。
4. 作成ゲート： gh pr create が正常に終了し、プルリクエストのURL（または gh の出力に含まれるプルリクエスト番号／URL）が表示されます。合格条件： URL（またはID）が記録されていること。コマンドが失敗した場合は、プルリクエストを作成したと主張しないでください。

1. コンテキストの収集

まず、変更内容に関する情報を収集します。

# Get current branch and verify it's not main
git branch --show-current

# Get commit history for this branch
git log --oneline main..HEAD

# Get detailed commit messages for context
git log --format="### %s%n%n%b" main..HEAD

# Get file change statistics
git diff --stat main..HEAD

# Get the actual diff for understanding changes
git diff main..HEAD

2. 変更内容の分析

収集した情報に基づいて、次の内容を判断します。

• 変更内容：変更を分類します（機能、修正、リファクタリング、ドキュメント、テスト）
• 変更理由：コミットメッセージとコードの変更から、動機を推測します
• 影響：破壊的変更、新しい依存関係、必要な移行
• テスト：追加／変更されたテストと、手動での確認方法

3. 関連するIssueの確認

Issueへの参照を探します。

• コミットメッセージ内（例：「fixes #123」、「closes #456」）
• ブランチ名内（例：fix/issue-123-description）
• 対応するコードコメントやTODO内

4. プルリクエストの説明を作成

次のテンプレート構成を使ってプルリクエストを作成します。

gh pr create --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
## Summary

<1-3 sentence overview of what this PR does and why>

## Changes

<Categorized bullet list of changes>

### Added
- <new features or capabilities>

### Changed
- <modifications to existing functionality>

### Fixed
- <bug fixes>

### Removed
- <deprecated or removed functionality>

## Motivation

<Why were these changes needed? What problem does this solve?>

## Testing

<How was this tested?>

- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing performed

### Manual Testing Steps

<If applicable, steps to manually verify the changes>

## Breaking Changes

<If any, describe what breaks and migration path. Remove section if none.>

## Related Issues

<Link to related issues. Remove section if none.>

- Closes #<issue_number>
- Related to #<issue_number>

## Checklist

- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Tests pass locally
- [ ] Linting passes
- [ ] Documentation updated (if needed)
EOF
)"

プロジェクトの慣例に応じて、任意でフッターのトレーラー（例：ツールの帰属を示す行）を追加します。プロジェクトにそのような慣例がない場合は省略してください。

5. タイトルの形式

プルリクエストのタイトルには、Conventional Commitsの形式を使います。

• feat(scope): add new feature
• fix(scope): correct bug behavior
• refactor(scope): restructure without behavior change
• docs(scope): update documentation
• test(scope): add or modify tests
• chore(scope): maintenance tasks

6. ラベルを適用

プルリクエストの作成後、変更内容に適切なラベルを適用します。gh pr edit <number> --add-label <label> を使います。

まず、リポジトリで利用可能なラベルを確認します。

gh label list

よく使われる種類別ラベル

ラベル	使用する場合
enhancement	新機能、機能追加、または改善
bug	バグ修正
documentation	ドキュメントのみの変更
breaking-change	移行が必要となる、ユーザー向けの破壊的変更

破壊的変更の基準

breaking-change は、ユーザーが次の内容を変更する必要があるユーザー向けの変更にのみ適用します。

• 設定ファイル
• CLIの呼び出し
• API連携

外部の利用者に影響しない内部のリファクタリングには適用しないでください。

7. 作成後

プルリクエストの作成後：

1. 適用したラベルとともに、プルリクエストのURLを表示します
2. 適切であれば、レビュアーの追加を提案します
3. 合格が必要なCIチェックがあれば、その旨を記載します

ガイドライン

すること：

• 何を変更したのか、なぜ変更したのかを具体的に記載する
• テストの根拠を含める
• 関連するIssueへのリンクを含める
• 破壊的変更を目立つように記載する
• 内容のない任意のセクションを削除する

しないこと：

• 関係のないコミットを含める（プルリクエストの対象を絞る）
• 説明にプレースホルダーのテキストを残す
• テストのセクションを省略する
• ローカルチェックを実行せずにプルリクエストを作成する