plan-merge-order

複数の PR を作成・マージする際の順序を事前計画してください。対象: $ARGUMENTS

手順

0. Preflight 検証 (前提)

マージ順序を計算する前に、対象 PR が本当にマージ対象かを検証する。/preflight $ARGUMENTS を先に実行するか、以下を直接実行する:

git fetch origin main
git log origin/main --oneline -15                                    # main に関連コミットが既にあるか目視

# 対象 PR ごとに REST API で state を直接取得 (gh pr view の GraphQL はキャッシュ遅延あり)
for pr in <PR numbers>; do
  gh api repos/OWNER/REPO/pulls/$pr --jq '{number, state, merged, merged_at, mergeable_state}'
done

# 類似キーワードで並行 in-flight PR を検索
gh pr list --state open --search "<keyword>" --json number,title,headRefName,author

# 直近 close 済 PR も確認 (並行作業の痕跡)
gh pr list --state closed --search "<keyword>" --limit 5 --json number,title,mergedAt

判定基準:

• 対象 PR に merged=true が含まれる → その PR を対象から除外してユーザーに報告
• 類似 keyword の別 open PR が存在 → 並行作業あり、続行前にユーザー確認
• main に同内容のコミット既に存在 → タスク obsolete の可能性、続行前にユーザー確認

この Step を飛ばして依存グラフ作成に進んではならない。gh pr list のキャッシュ遅延で closed PR を OPEN と誤判定し、重複作業・force-push 計画・stale commits 分析に時間を費やした事例が複数回発生している (2026-04-11 セッションで 4 重複 PR)。

1. 対象 PR の収集

各 PR について以下を取得:

gh pr diff <number> --name-only

変更ファイルリストを記録する。

2. 依存グラフの作成

PR 間の関係を3種類に分類:

• 包含関係: PR A の変更が PR B に全て含まれている → A をマージして B をクローズ
• ファイル衝突: 同じファイルを変更する → 先にマージした方の変更を他方がリベースで取り込む必要あり
• 独立: 変更ファイルが重ならない → 順序に依存しない

3. マージ順序の決定

優先ルール:

1. 独立 PR を最初にマージ — コンフリクトリスクなし
2. 包含される PR を先にマージ — 上位 PR は後で rebase
3. ファイル衝突 PR はボトムアップ — 変更量の少ない PR を先に
4. hot file を触る PR は特に慎重 — src/lib/review-engine.mjs, src/lib/local-runner.mjs, src/lib/verifier.mjs など

4. レポート出力

以下の形式（プレースホルダー）で結果を報告:

<!-- 以下は出力テンプレート例。実際の PR 番号・ファイル名・行番号に置き換えて使用 -->

## マージ順序計画

### 依存グラフ

- PR #<number> → PR #<number> （ファイル衝突: <file>, <file>）
- PR #<number> （独立）

### 推奨マージ順序

1. PR #<number>（独立、ファイル衝突なし）
2. PR #<number>（ボトムアップ: 変更量少）
3. PR #<number>（リベース必要: 上流マージ後にファイル X が変更されている）

### リベース予想コスト

- PR #<number>: `<file>:<line>` 付近で約 N 行のコンフリクト見込み

Hot File リスト