Resolve PR Conflict

指定されたPR番号のPRがターゲットブランチ（baseRefName）とコンフリクトしていないかを確認し、コンフリクトがあればrebaseで解消したうえで--force-with-leaseでpushするスキル。レビュー指摘の対応・修正プランの評価・ラベル付与・マージ判定といった他の責務には立ち入らない。

このスキルがやること・やらないこと

やること:

• gh pr checkoutによるPRブランチへの切り替え
• ターゲットブランチとのコンフリクト有無の判定
• コンフリクトがある場合のrebase実行・コンフリクト解消・--force-with-leaseでのpush

絶対にやらないこと:

• コンフリクト解消以外の目的でのコード変更（リファクタリング、レビュー指摘対応、Lint修正、テスト追加など）
• rebase以外での新規commit作成（git commit単体での新規commitは作らない）
• PRへのラベル付与・コメント投稿・マージ・close（上位スキルの責務）
• git push --force（--force-with-lease以外のforce-push）

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の resolve-conflict ワーカー（cc-resolve-conflict ラベル）から自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-resolve-conflict の除去を進める。処理が未完のままターンを終えると、rebase未完了のまま triage-pr ワーカーが再度PRを拾ってコンフリクトを再検知する無限ループや、リモート未反映のまま次工程に進む状態壊れが起きる。

$ARGUMENTSがPR番号を表す。空・非数値・複数値の場合は、その旨を出力して即中断する。

ステップ0: 作業ディレクトリの安全確認

このスキルは単独でも triage-pr 等からの委譲でも起動される。いずれのケースでも、呼び出し元が用意した作業コンテキストを尊重するため、現在地を変更しない・新規worktreeを作らない。

pwd

判定:

• .claude/worktrees/ 配下にいる場合: そのworktree内で全ての作業（gh pr checkout / git rebase / git push）を完結させる。cdでworktreeの外やリポジトリのルートに移動しない
• .claude/worktrees/ 配下にいない場合（リポジトリのルート・通常のクローン等）: その場で作業する。.claude/worktrees/ 配下への移動や新規worktree作成はしない

加えて、デフォルトブランチで直接rebase / force-pushを行う事故を避けるため、gh pr checkout の 直後（ステップ1）で現在ブランチがデフォルトブランチと一致しないことを確認する（一致した場合は中断する）。

ステップ1: PRの存在確認とチェックアウト

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

gh pr view $ARGUMENTS --json number,state,baseRefName,headRefName

stateがOPEN以外（MERGED / CLOSED）の場合や、PR自体が存在しない場合は、その旨を出力して中断する（CLOSED/MERGED済みPRへのforce-pushは無意味で誤操作リスクの方が大きいため）。

存在を確認できたら、現在地でそのままPRブランチをチェックアウトする（新規worktreeは作らない）。

git fetch -p
gh pr checkout $ARGUMENTS

（gh pr checkout はローカル作業ツリーへの checkout であり、リモート API では代替できないため gh のまま残す）

クラウド実行時は実行しない。 クラウドセッションはワーカーが --on-branch で指定した PR の head ブランチ上で開始しており、既に目的のブランチにいる（gh pr checkout は GraphQL 経由でもあり、クラウドでは 403 で失敗する）。ワーカーが起動プロンプトへ同じ趣旨の指示を入れているが、git rev-parse --abbrev-ref HEAD が既に対象PRの head ブランチを指している場合も同様に checkout を省略してよい。

チェックアウトを省略した場合のfail-safe: git rev-parse --abbrev-ref HEAD の値が、ステップ1冒頭で取得済みの headRefName と一致することを確認する。一致しない場合は --on-branch が反映されていない想定外の状態のため、rebase・force-pushを行わずその場で中断する。

gh pr checkoutが失敗した場合（作業ツリーが汚れている、ローカルに同名のブランチがある等）は、原因をそのまま出力して中断する。git stashやgit reset --hardを独断で行ってユーザーの未コミット変更を失わせないこと。

チェックアウト成功後、fail-safeとしてブランチがデフォルトブランチでないことを確認する。

DEFAULT_BRANCH=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)

CURRENT_BRANCHがDEFAULT_BRANCHと一致する場合は中断する（想定外の状態でrebase/force-pushがデフォルトブランチに走るのを防ぐため）。gh-compat.sh default-branchが失敗してデフォルトブランチ名が取得できない場合も、判定不能として中断する。

ステップ2: ターゲットブランチとのコンフリクト判定

ターゲットブランチはbaseRefNameから動的に取得する。デフォルトブランチではなく、PRが実際にマージされる先のブランチを基準にすること（Epic PRなど、デフォルトブランチ以外をターゲットにするケースに対応するため）。

コンフリクト有無の一次判定には、呼び出し元のtriage-prと同じGitHubのmergeableフィールドを使う。判定基準を呼び出し元と揃えないと、「triage-prはコンフリクトありと判定したのに本スキルはなしと判定して何もせず終了する」という食い違いが起き、cc-resolve-conflictラベルの付与と除去が繰り返される無限ループになる。

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

TARGET_BRANCH=$(gh pr view $ARGUMENTS --json baseRefName -q .baseRefName)
MERGEABLE=$(gh pr view $ARGUMENTS --json mergeable -q .mergeable)

判定基準:

• CONFLICTING: コンフリクトありと判定し、ステップ3に進む

• MERGEABLE: コンフリクトなしと判定する

• UNKNOWN: GitHub側で判定中のため、数秒スリープして1回だけ再取得する。それでもUNKNOWNの場合は、ローカルで実マージ相当の判定にフォールバックする

  git merge-tree --write-tree "origin/$TARGET_BRANCH" HEAD
  

  終了コードが1なら「コンフリクトあり」、0なら「コンフリクトなし」。--write-treeモードは実際のマージと同じmerge-ortエンジンで判定するため、コンテンツ競合だけでなくrename・modify/delete・バイナリ・ファイルモード変更のコンフリクトも検知できる（Git 2.38以上が必要。コマンド自体が失敗して判定できない場合は「コンフリクトあり」側に倒してステップ3に進む）

禁止: 旧形式のgit merge-tree <base-tree> <branch1> <branch2>（trivial mergeモード）の出力にコンフリクトマーカー（<<<<<<<等）が含まれるかで判定してはならない。旧形式はrename検知を行わず、modify/delete・バイナリ・モード変更などのコンフリクトではマーカーを出力しないため、GitHubがCONFLICTINGと判定しているPRを「コンフリクトなし」と誤判定し、triage-prとの間で無限ループを引き起こす。

コンフリクトなしの場合

「コンフリクトなし」を呼び出し元に返却して終了する。git rebaseもpushも行わない（不要なrebase/force-pushはCIを無駄に再走させ、他者がそのブランチを見ているときの混乱の元になるため）。

コンフリクトありの場合

ステップ3に進む。

ステップ3: rebaseによるコンフリクト解消

git rebase "origin/$TARGET_BRANCH"

rebaseがコンフリクトなしで完走した場合も、そのままステップ4のpushに進む（GitHubのCONFLICTING判定はマージ試行に基づくため、rebase自体はクリーンに完走することがある。ここでpushせず終了するとリモートが変わらず、triage-prが再度コンフリクトを検知してループする）。

rebase中にコンフリクトが発生した場合は、git statusでコンフリクト中のファイルを特定する。

.penファイル（Pencilデザインファイル）のコンフリクトは例外: .penは暗号化バイナリのため、コンフリクトマーカーの手編集によるテキストマージは絶対に行わない（ファイルが破損する）。resolve-pencil-conflictスキルをSkillツールで起動し、「片側採用 → もう一方をPencilで再適用」のフローで解消する（rebase中は ours = ターゲットブランチ側 / theirs = PR側と意味が反転する点に注意）。Pencil CLIが利用できない等でこのフローを実行できない場合は、無理に解消せずgit rebase --abortで中断する。

.pen以外のファイルは、それぞれを 両者の変更意図を尊重する形 で解消する。片方の変更を機械的に捨てると、PR側のレビュー意図かターゲットブランチ側の最新仕様のどちらかを取りこぼすため、必要に応じて以下を行ってから解消する。

• Readで該当ファイル全体を読み、コンフリクトしている関数/ブロックの責務を理解する
• git log -pでターゲットブランチ側・PR側それぞれの該当変更commitを確認し、変更意図を読み取る
• 周辺コードや関連テストをRead / Grepで参照し、整合性のとれた解消にする

判断できない場合（情報が足りない、両方が同じ箇所を大きく書き換えている、人間の仕様判断が必要、など）は無理に解消せず、git rebase --abortで取り消したうえで中断理由を呼び出し元に返却する（生半可な解消はレビュー差し戻しや本番バグ混入につながるため）。

解消後：

git add <解消したファイル>
git rebase --continue

複数commitにまたがって連続してコンフリクトする場合は、各commitで同じ手順を最後まで繰り返す。

ステップ4: force-push

git push origin HEAD --force-with-lease

--force-with-leaseを使うのは、自分の認識していないリモートの新規commitを上書きしない（他人のpushを巻き戻さない）ため。pushが失敗した場合は、エラー内容をそのまま呼び出し元に返却して中断する。自動再試行はしない（再試行が必要なケースはリモートに新規pushが来ているなど人間判断が必要な状況のため）。

出力

呼び出し元には以下を構造化して返却する。

• 判定: no-conflict / resolved-and-pushed / aborted のいずれか
• 詳細:
  • no-conflict: ターゲットブランチ名と判定根拠（mergeableの値、またはフォールバック時はgit merge-tree --write-treeの結果）
  • resolved-and-pushed: 解消したファイル一覧と各ファイルの解消方針の要点
  • aborted: 中断理由（PRがOPENでない / checkout失敗 / コンフリクト解消困難 / push失敗 など）と、その時点のgitの状態（git statusの要約）

注意事項

• スコープは コンフリクト解消のみ。ステップ3のrebase中のEdit / Write以外でコードを変更しない。コンフリクトと無関係な「ついで修正」を入れると、後続のレビューと履歴が複雑になる
• PRに付与されているラベル（cc-triage-scope等を含む）は一切操作しない。ラベル管理は上位スキルの責務
• git push --forceは使わず、必ず--force-with-leaseを使う