resolve-conflicts

$ARGUMENTS[0] で指定されたブランチを現在のブランチに merge し、コンフリクトを解決してください。 引数が空の場合は main を対象にしてください。

進め方

1. 取り込みブランチの決定

   • $ARGUMENTS[0] が指定されていれば、それを TARGET_BRANCH とする
   • 空なら TARGET_BRANCH=main をデフォルトとする
   • 以降の手順では origin/$TARGET_BRANCH を merge 対象として扱う

2. 作業前の確認（並列実行可）

   • git status --short で未コミット変更がないことを確認（あれば stash かコミットを促す）
   • 現在のブランチ名を確認
   • git fetch origin $TARGET_BRANCH で対象ブランチを最新化

3. merge の実行

   • git merge origin/$TARGET_BRANCH を実行
   • コンフリクトが発生したらマーカー（ <<<<<<<, =======, >>>>>>> ）のあるファイル一覧を列挙

4. コンフリクトの内容を理解してから解消

   • 両側（HEAD / 取り込み側）の変更が 何を意図しているかを読み取る
   • 単純に片方を残すのではなく、両者の意図を満たす解を選ぶ
   • 機械的な決定を避けたいケース（ロジック競合・型変更が絡む・テストの期待値差分）は、解消した理由を控えておく
   • _test.go や mock 等の自動生成系で衝突する場合は手で merge せず再生成（ task go:gen 等）を優先

5. 検査での確認（ verify_merge_with_checks.md ）

   • 衝突が0件でも必ず走らせる。git の成功は「同じ行を触っていない」ことしか意味しない
   • 軽い順に lint → 型検査 → テスト。落ちた層がそのまま原因の場所になる
   • push する先で CI がテストを回すなら、手元で通すのは lint と型検査まで。 テストの完了を待って push を止めない。CI の結果を回収して、落ちていたら直す（ ~/.claude/references/decide_or_ask.md の「push も、CI が回すテストを手元で待たない」）
   • 型検査を飛ばさない。片方が移動・削除した対象を、もう片方が新しく足したファイルから参照している「参照切れ」は、そのファイルを通るテストが無いと出ない
   • lint の警告も残さない。死んだ import と変数はマージで生まれやすい
   • mock 再生成が必要なら忘れず実施
   • 直すのは切り出し先まで。呼び出し側だけ新しい形に合わせると、中身が古いまま型が通る

6. merge コミット作成

   • git add で解消済みファイルを stage
   • git commit で merge コミットを作成（ --no-edit ではなく、必要に応じてメッセージを編集）
   • git push までは行わない。ユーザーが意図して push する流れに任せる

7. 完了報告

   • 取り込み対象ブランチ
   • 衝突したファイル一覧
   • 各ファイルで「どちらの意図を採用したか / どう統合したか」
   • 再生成した自動生成ファイルがあればその旨
   • 解消できなかった懸念点（テストが落ちる / 仕様検討が要る）があれば明示

出力の目安

• 衝突なし: 取り込んだブランチと「衝突なし」を1〜2行で
• 衝突あり: ファイルごとに「どちらの意図を採用したか / どう統合したか」を1行ずつ。自動生成物は再生成した旨を添える
• いずれも、解消できなかった懸念（テストが落ちる / 仕様検討が要る）があれば最後に明示する

やってはいけないこと

• コンフリクトマーカーを機械的に片側だけ残して解消すること（両側の意図を読んでから判断する）
• _test.go / mock などの自動生成物を手で merge すること（再生成するのが正しい）
• 解消後の merge コミットを push すること（push はユーザーの判断に委ねる）