split-pull-request-rule

Split Pull Request Rule

大きな変更を、ジュニアエンジニアでも 10 分以内に確認できる Pull Request 群へ分ける。 本 SKILL は分割方針・ブランチ名・依存関係の提案までを担う。実際のブランチ作成・コミット・gh pr create は行わない。

いつ使うか

• ユーザーが PR 分割を指示したとき
• 差分・計画・実装が 1 PR ではレビュー負荷が高そうで、分割を検討すべきとき
• Stacked PR（依存する一連の PR）として出す前提で、順序とブロッキングを整理したいとき
• /split-to-prs など実行系と組み合わせ、先に「どう分けるか」を固めるとき

いつ使わないか

• 単純に 1 本の PR を作成・更新するだけのとき（本文起草・gh pr create のみ）
• ブランチ命名規則だけが論点のとき（分割が不要な場合）
• コード実装・バグ修正そのもので、PR 境界の設計が不要なとき

役割分担

役割	担当
分割方針・PR 一覧・依存グラフ・ブランチ名案	本 SKILL
ブランチ作成・コミット分割・PR 作成の実行	/split-to-prs 等の実行系（ユーザー承認後）

分割により元ブランチのコミット履歴が失われてもよい。履歴保全よりレビュー粒度を優先する。

分割方針（優先度順）

1. 確認時間: 1 PR は、想定レビュアー（ジュニアエンジニア）が 10 分以内 に確認できる粒度にする（最優先）
2. 低レイヤー → 高レイヤー: 独立した関連機能ごとに PR を切り、下位からマージできる順にする
3. 完全独立機能: 本実装の本筋と論理的に独立している変更は別 PR にする（先行または並行。blocking が無ければ non-blocking）
   • 例: 共通モジュールへの特定の共通 UI 追加、新しい共通モジュールの追加、実装に先立つ既存テストのカバレッジ増加
4. インターフェースと実装: 分離しているなら別 PR。順序はインターフェース → 実装（＋その Unit Test）
5. 実装と Unit Test: 紐づく実装と Unit Test は同一 PR
6. 単一関心への紐付け: ある機能（クラス・関数など）にだけ属する変更は同一 PR でよい
7. 限定スコープ: private 等、呼び出し範囲が狭いものは呼び出し元と同一 PR
8. UI 境界: 画面実装があり MVVM 等で境界がある場合は、Model+ViewModel → View のように境界で分割する（同等の分離があれば同じ考え方）
9. アーキテクチャレイヤー: レイヤーが分かれているならレイヤーごとに分割する
10. テスト前提データ: テスト用・ダミーデータの追加など、「あるテストの前提」かつ独立レビューすべきものは別 PR
11. 前提整備: 「本実装の前提として既存コードを先に直す」類は先行 PR に切り出す

言語・フレームワーク固有の用語に依存せず、リポジトリの実際の境界（パッケージ、モジュール、レイヤー、公開 API）に当てはめて判断する。

ブランチ名

分割後の各ブランチは次の形式にする。

{元のブランチ名}-{通し番号}-{内容}

• {元のブランチ名}: 分割元の作業ブランチ名をそのまま使う
• {通し番号}: 01, 02, … のようにゼロ埋め 2 桁を推奨（推奨マージ順と揃える）
• {内容}: その PR の関心が分かる短い英数字・ハイフン（例: add-auth-interface, impl-auth, ui-login）

例: 元ブランチが feature/id/42/add-login のとき

• feature/id/42/add-login-01-auth-interface
• feature/id/42/add-login-02-auth-impl
• feature/id/42/add-login-03-login-view

依存関係（Stacked PR 前提）

Stacked PR が有効であることを前提に、PR 間の依存を次で区別する。

• blocking（ブロッキング）: 後続 PR のレビュー・マージ前に、先行 PR のマージ（または同等の取り込み）が必要
• non-blocking（非ブロッキング）: 並行レビュー可能。マージ順の好みやコンフリクト回避のための順序付けはあるが、論理的には独立