roo-conflict-resolution

Roo Code のコンフリクト解決スキル

このスキルを使用する場合

次のようなタスクでは、このスキルを使用してください。

• 特定のプルリクエストのマージコンフリクトを解決する
• ターゲットブランチとのコンフリクトがあるブランチをリベースする
• コンフリクトしているコード変更を理解して分析する
• どの変更を保持、統合、破棄するかを適切に判断する
• コンフリクト解決の判断に git の履歴を活用する

このスキルを使用しない場合

次のような場合は、このスキルを使用しないでください。

• 解決が必要なマージコンフリクトがない
• タスクがコンフリクトのない一般的なコードレビューである
• マージが発生する状況のない、新規コードを扱っている

ワークフローの概要

このスキルでは、git の履歴、コミットメッセージ、コード変更を分析し、適切な解決方法を判断することでマージコンフリクトを解決します。PR 番号（例：「#123」）を指定すると、コンフリクト解決の全プロセスを処理します。

初期化手順

ステップ 1：PR 番号を解析する

「#123」や「PR #123」のような入力から PR 番号を抽出します。PR 番号が指定されていることを確認します。

ステップ 2：PR 情報を取得する

gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName

PR のタイトルと説明を取得して、その意図を把握し、ソースブランチとターゲットブランチを特定します。

ステップ 3：PR ブランチをチェックアウトしてリベースの準備をする

gh pr checkout [PR_NUMBER] --force
git fetch origin main
GIT_EDITOR=true git rebase origin/main

• PR ブランチを強制的にチェックアウトして、クリーンな状態を確保します
• 最新の main ブランチを取得します
• main へのリベースを試み、コンフリクトを明らかにします
• 対話なしでリベースできるように GIT_EDITOR=true を使用します

ステップ 4：マージコンフリクトを確認する

git status --porcelain
git diff --name-only --diff-filter=U

マージコンフリクトのあるファイル（「UU」とマークされたファイル）を特定し、解決が必要なファイルの一覧を作成します。

主なワークフローのフェーズ

フェーズ 1：コンフリクト分析

コンフリクトのある各ファイルを分析し、変更内容を把握します。

1. コンフリクトのあるファイルを読み、コンフリクトマーカーを特定します
2. <<<<<<< と >>>>>>> の間にあるコンフリクト箇所を抽出します
3. コンフリクトの両側で git blame を実行します
4. 関連するコミットのメッセージと差分を取得します
5. 各変更の意図を分析します

フェーズ 2：解決方針

各コンフリクトに最適な解決方針を決定します。

1. 変更を意図（バグ修正、機能、リファクタリングなど）ごとに分類します
2. 変更の新しさと関連性を評価します
3. 構造上の重複と書式の違いを確認します
4. 変更を統合できるか、どちらか一方で上書きすべきかを特定します
5. テストの更新や関連する変更を考慮します

フェーズ 3：コンフリクト解決

解決方針を適用してコンフリクトを解決します。

1. 各コンフリクトに、選択した解決方法を適用します
2. 差分内のコンフリクトマーカーが適切にエスケープされていることを確認します
3. 解決後のコードが構文的に正しいことを検証します
4. 解決したファイルを git add でステージングします

フェーズ 4：検証

解決内容を確認し、コミットの準備をします。

1. git status を実行し、すべてのコンフリクトが解決されていることを確認します
2. コンパイルエラーや構文エラーがないか確認します
3. 最終的な差分を確認し、妥当な解決になっていることを確かめます
4. 解決の判断内容をまとめます

git コマンドのリファレンス

コマンド	用途
gh pr checkout [PR_NUMBER] --force	PR ブランチを強制的にチェックアウトします
git fetch origin main	最新の main ブランチを取得します
GIT_EDITOR=true git rebase origin/main	現在のブランチを main にリベースします（対話なし）
git blame -L [start],[end] [commit] -- [file]	指定した行のコミット情報を取得します
git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]	コミットのメタデータを取得します
git show [sha] -- [file]	コミットで行われた実際の変更を取得します
git ls-files -u	マージ未完了のファイルをステージ情報とともに一覧表示します
GIT_EDITOR=true git rebase --continue	コンフリクトを解決した後、リベースを続行します

ベストプラクティス

意図に基づく解決（優先度：高）

コードの差分だけを見るのではなく、変更の背後にある意図の理解を常に優先してください。コミットメッセージ、PR の説明、Issue への参照は、重要なコンテキストを提供します。

例： バグ修正とリファクタリングが競合する場合は、どちらか一方を選ぶのではなく、リファクタリング後の構造にバグ修正のロジックを適用します。

価値のある変更をすべて維持する（優先度：高）

可能な場合は、片方の変更をすべて破棄するのではなく、競合しない変更を両方から組み合わせてください。競合する変更の両側には、多くの場合、適切に統合すれば共存できる価値のある変更が含まれています。

競合マーカーをエスケープする（優先度：高）

apply_diff を使用するときは、解析エラーを防ぐため、マージ競合マーカーを必ずバックスラッシュでエスケープしてください。

• 正しい例：\<<<<<<< HEAD
• 誤った例：<<<<<<< HEAD

関連する変更を考慮する（優先度：中）

目の前の競合だけでなく、テスト、ドキュメント、依存コードにおける関連する変更も確認してください。一見独立しているように見える変更も、より大きな機能や修正の一部である可能性があります。

解決のヒューリスティクス

カテゴリ	ルール	例外
バグ修正と機能	通常、バグ修正を優先します	機能に修正が含まれている場合
新しい変更と古い変更	より新しい変更のほうが関連性が高いことが多いです	古い変更がセキュリティパッチである場合
テストの更新	テストの更新を伴う変更は、より完全である可能性が高いです	-
フォーマットとロジック	フォーマットよりロジックの変更を優先します	-

よくある落とし穴

片方を無条件に選ぶ

問題： 重要な変更を失ったり、リグレッションを引き起こしたりする可能性があります。 解決策： git blame とコミット履歴を使って、常に両側を分析してください。

PR のコンテキストを無視する

問題： PR の説明には、変更の背景にある理由が記載されていることがよくあります。 解決策： 解決する前に、必ず PR 情報を取得して確認してください。

解決後のコードを検証しない

問題： マージしたコードに構文エラーがあったり、ロジック上の問題が生じたりする可能性があります。 解決策： 構文エラーがないか必ず確認し、最終的な差分をレビューしてください。

差分内の未エスケープの競合マーカー

問題： エスケープされていない競合マーカー（<<<<<<、=======、>>>>>>）は差分の構文として解釈されます。 解決策： 内容に含まれる場合は、必ずバックスラッシュ（\）でエスケープしてください。

差分の適用例

apply_diff で競合を解決するときは、次の形式を使用してください。

<<<<<<< SEARCH
:start_line:45
-------
\<<<<<<< HEAD
function oldImplementation() {
  return "old";
}
\=======
function newImplementation() {
  return "new";
}
\>>>>>>> feature-branch
=======
function mergedImplementation() {
  // Combining both approaches
  return "merged";
}
>>>>>>> REPLACE

品質チェックリスト

解決前

• コンテキストを把握するために PR のタイトルと説明を取得する
• 競合があるすべてのファイルを特定する
• マージする変更全体を理解する

解決中

• 競合するセクションに対して git blame を実行する
• 意図を確認するためにコミットメッセージを読む
• 変更を組み合わせられるか検討する
• 差分内の競合マーカーをエスケープする

解決後

• 競合マーカーが残っていないことを確認する
• 構文エラーやコンパイルエラーがないか確認する
• 差分全体をレビューする
• 解決の判断を記録する

完了条件

• すべてのマージ競合が解決されている
• 解決したファイルがステージングされている
• 解決後のコードに構文エラーがない
• 解決の判断が記録されている

コミュニケーションのガイドライン

解決の進捗を報告する際は、次の点に従ってください。

• 解決の判断を説明する際は、率直かつ技術的に伝える
• 各競合を解決した根拠を中心に説明する
• 何をマージしたのか、その理由とともに明確に要約する

進捗報告の形式

Conflict in [file]:
- HEAD: [brief description of changes]
- Incoming: [brief description of changes]
- Resolution: [what was decided and why]

完了メッセージの形式

Successfully resolved merge conflicts for PR #[number] "[title]".

Resolution Summary:
- [file1]: [brief description of resolution]
- [file2]: [brief description of resolution]

[Key decision explanation if applicable]

All conflicts have been resolved and files have been staged for commit.