github-pr-creation

GitHub PR の作成

タスクの検証、テストの実行、Conventional Commits 形式に基づいてプルリクエストを作成します。

現在の状態

!git rev-parse --abbrev-ref HEAD 2>/dev/null !git log @{u}..HEAD --oneline 2>/dev/null || echo "(no upstream tracking)"

基本的なワークフロー

1. ターゲットブランチを確認する

続行する前に、必ずユーザーに確認してください：

Creating PR from [current-branch] to [target-branch]. Correct?

ブランチの流れ	一般的なターゲット
feature/*	develop
fix/*	develop
hotfix/*	main/master
develop	main/master

2. タスクのドキュメントを検索する

このプルリクエストで達成すべき内容を記述したタスク／仕様ファイルを探します。ツールごとの一般的な場所：

ツール／規約	パス
Spec2Ship (s2s)	.s2s/plans/*.md（ブランチ名またはコミットに一致する進行中のプランを探します）
AWS Kiro	.kiro/specs/*/tasks.md
Cursor	.cursor/rules/*.md, .cursorrules
Trae	.trae/rules/*.md
GitHub Issues	gh issue list --assignee @me --state open
一般	docs/specs/, specs/, tasks.md, TODO.md

見つかった場合は、タスク ID、タイトル、説明、要件への参照を抽出します。

3. コミットを分析する

このブランチ上の各コミットについて、タイプ、スコープ、タスクへの参照、破壊的変更を特定します。タスクファイルがある場合は、コミットを記載されたタスクに対応付けます。

4. タスクの完了を確認する

タスクのドキュメントがある場合：

1. ブランチ名からメインタスクを特定します（例：feature/task-2-* -> タスク 2）
2. すべてのサブタスクを探します（例：タスク 2.1、2.2、2.3）
3. コミット内で参照されているサブタスクを確認します
4. 未完了のサブタスクを報告します

タスクが未完了の場合は、処理を停止して状況を表示します：

Task 2 INCOMPLETE: 1/3 sub-tasks missing
- Task 2.1: done
- Task 2.2: done
- Task 2.3: MISSING

不足しているタスクを完了するか、そのまま進めるかをユーザーに確認します。

5. テストを実行する

プロジェクトのテストスイートを実行します。プルリクエストを作成する前に、テストが必ず合格している必要があります。

6. プルリクエストのタイプを判定し、タイトルを生成する

ブランチの流れ	タイトルの接頭辞
feature/* -> develop	feat(scope):
fix/* -> develop	fix(scope):
hotfix/* -> main	hotfix(scope):
develop -> main	release:
refactor/* -> develop	refactor(scope):
chore/* -> develop	chore(scope):
ci/* -> develop	ci(scope):
docs/* -> develop	docs(scope):

タイトル形式：<type>(<scope>): <description>

• タイプ：分析で判定した主要なコミットタイプ（feat > fix > refactor > ci > chore）
• スコープ：コミットで最も多く使われているスコープ（ケバブケース）
• 説明：命令形、小文字、末尾にピリオドを付けず、最大 50 文字

破壊的変更：コミットに BREAKING CHANGE: またはタイプの後に ! が含まれる場合：

• プロジェクトに breaking ラベルがあれば追加します
• プルリクエスト本文に ## Breaking changes セクションを含めます

7. プルリクエスト本文を生成する

PR のタイプに基づいて references/pr_templates.md の適切なテンプレートを使用し、収集したデータを記入します。

8. ラベルを提案する

必ず、先に利用可能なラベルを確認してください：

gh label list

コミットタイプを、プロジェクトで利用可能なラベルに対応付けます。プロジェクトでは標準とは異なる名前（例：「enhancement」ではなく「feature」）が使われている場合があります。

コミットタイプ	一般的なラベル名
feat	feature, enhancement
fix	bug, bugfix
refactor	refactoring, tech-debt
docs	documentation
ci	ci/cd, infrastructure
security	security
hotfix	urgent, priority:high

一致するラベルがない場合：新しいラベルの作成を提案します。ユーザーがデフォルトのラベルを削除している可能性があるため、関連するラベルの追加を提案するのが適切です。

9. マイルストーンを判定する

オープン中のマイルストーンを確認します：

gh api repos/$(gh repo view --json nameWithOwner -q '.nameWithOwner')/milestones \
  --jq '.[] | select(.state == "open") | "\(.number): \(.title)"'

• アクティブなマイルストーンが 1 つの場合：プルリクエストをそのマイルストーンに割り当てます（進行中の作業はすべて次のリリースに含まれます）
• マイルストーンが複数ある場合：どれを適用するかユーザーに確認します
• マイルストーンがない場合：スキップします（自動作成しないでください）

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

必ず、タイトル、本文、ラベル、マイルストーンを提示し、先にユーザーの承認を得てください。

gh pr create \
  --title "[title]" \
  --body "$(cat <<'EOF'
[body content]
EOF
)" \
  --base [base_branch] \
  --label "[label1]" --label "[label2]" \
  --milestone "[milestone-title]" \
  --reviewer "[username]"          # if teammates are known

プルリクエストがまだマージレビューの準備ができていない場合（作業中、CI 待ち、またはブランチ上で AI ボットによるレビューをトリガーする目的でのみ作成する場合）は、--draft を使用します。

重要なルール

• 必ず ユーザーに対象ブランチを確認してください
• 必ず PR を作成する前にテストを実行してください
• 必ず PR を作成する前に、承認を得るために PR の内容を提示してください
• 必ず 提案する前に gh label list で利用可能なラベルを確認してください
• 必ず 書式を保持できるよう、本文には HEREDOC を使用してください
• 必ず 各ラベルに個別の --label を指定してください（1 つの文字列にカンマ区切りで指定しないでください）
• 必ず オープン中のマイルストーンを確認し、アクティブなものがあれば割り当ててください
• 絶対に ユーザーの確認なしに PR を作成しないでください
• 絶対に リポジトリのファイルを変更しないでください（読み取り専用の分析）
• 絶対に マイルストーンを自動で作成しないでください。既存のもののみ割り当ててください
• マージレビューの準備ができていない PR には --draft を使用してください
• チーム設定または CODEOWNERS からチームメイトが分かる場合は、--reviewer を使用してください

参考資料

• references/pr_templates.md - 各種 PR（機能追加、リリース、バグ修正、ホットフィックス、リファクタリング、ドキュメント、CI/CD）用の PR 本文テンプレート