/merge-conflict

/merge-conflict - 体系的なマージコンフリクト解決

Language Mode

すべての出力は日本語で行う。詳細は language-enforcement スキルを参照。

---

git のマージコンフリクトを分析・解決・検証するための構造化ワークフロー。サブエージェント委任を活用する。

設計原則

1. 解決前に理解する: 判断を下す前に両バージョンを分析する
2. 意図を保持する: 両ブランチの変更目的を維持する
3. 解決を検証する: コンフリクト解決後は必ずテストを実行する
4. 判断を記録する: 特定の解決方法を選んだ理由を記録する

---

使用タイミング

• git merge でコンフリクトが発生した場合
• git rebase でコンフリクトが発生した場合
• cherry-pick がコンフリクトにより失敗した場合
• 複雑なコンフリクトに体系的なアプローチが必要な場合

入力形式

# 特定のファイルのコンフリクトを解決
/merge-conflict src/components/Auth.tsx

# 現在のすべてのコンフリクトを解決
/merge-conflict --all

# インタラクティブモード（一覧から選択）
/merge-conflict

---

実行手順

フェーズ 1: コンフリクト検出

目的: コンフリクトのあるすべてのファイルとその範囲を特定する。

重要: コンフリクト検出は code-explorer エージェントに委任する（git 分析コマンドを直接実行しないこと）:

code-explorer エージェントを起動:
タスク: すべての git マージコンフリクトを検出
実行:
- git diff --name-only --diff-filter=U（コンフリクトファイル一覧）
- git status --porcelain（コンフリクト概要の取得）
抽出:
- コンフリクトのあるファイルパス一覧
- 各ファイルのコンフリクトステータス（UU, AA, DD）
- コンフリクト総数
Thoroughness: quick
出力: [file_path, conflict_status] の構造化リスト

エージェントの出力をコンフリクト情報として使用する。検出・分析フェーズでは、親コンテキストで git 分析コマンド（diff, status, log, show）を直接実行しないこと。

エージェントがコンフリクトなしと報告した場合:

• コンフリクトが存在しないことをユーザーに通知する
• 現在の状態を確認するために git status の実行を提案する

TodoWrite リストを作成する（エージェントの出力を使用し、各コンフリクトファイルを1項目とする）。

フェーズ 2: コンフリクト分析

目的: 各コンフリクトについて、両サイドの変更内容を理解する。

各コンフリクトファイルに対して、並列エージェントを起動する:

重要: コンフリクトマーカーの抽出を含むすべての分析を code-explorer エージェントに委任すること。

code-explorer エージェントを並列起動:

エージェント 1（Ours）: "ours"（現在のブランチ）バージョンを分析
- どのような変更が行われたか？
- これらの変更の意図は何か？
- どのような依存関係があるか？

エージェント 2（Theirs）: "theirs"（取り込みブランチ）バージョンを分析
- どのような変更が行われたか？
- これらの変更の意図は何か？
- どのような依存関係があるか？

エージェント 3（コンフリクト分析）: コンフリクトの抽出と分類
- すべてのコンフリクトマーカー（<<<<<<< / ======= / >>>>>>>）を検出
- 行番号と周辺コンテキストを報告
- 各コンフリクトを分類（追加型 / 修正型 / 削除型 / 構造型）

Thoroughness: medium

エージェントの出力をコンフリクト情報として使用する。親コンテキストで grep を直接実行しないこと。

並列エージェントのエラーハンドリング:

シナリオ	対応
3つとも成功	完全な分析結果でフェーズ 3 に進む
1つ失敗	失敗したエージェントをスコープを縮小して1回リトライ。リトライも失敗した場合は部分的な分析で進行
2つ失敗	不完全な分析であることをユーザーに警告。リトライまたは慎重に進行するか選択させる
3つとも失敗	進行しない。ユーザーに選択肢を提示する

1〜2個のエージェントがリトライ後も失敗した場合:

Question: "一部の分析エージェントが失敗しました。このコンフリクトについて部分的な情報のみ取得できています。"
Header: "部分的な分析"
Options:
- "利用可能な分析で進行する（手動検証が必要な場合あり）"
- "すべての分析エージェントをリトライする"
- "代わりにコンフリクトマーカーをそのまま表示する"

3つすべてのエージェントが失敗した場合:

Question: "コンフリクト分析が完全に失敗しました。どのように進めますか？"
Header: "分析失敗"
Options:
- "コンフリクト分析をリトライする"
- "コンフリクトファイルを直接表示する（手動解決）"
- "このファイルを今はスキップする"

ユーザーが「コンフリクトファイルを直接表示する」を選択した場合、ファイルを読み取り（200行以下）、コンフリクトマーカーを表示する。

コンフリクトタイプの分類（エージェント出力を使用）:

タイプ	パターン	解決アプローチ
追加型	両サイドが異なるコードを追加	通常は両方を保持
修正型	両サイドが同じ行を修正	意味的なマージが必要
削除型	一方が削除、他方が修正	どちらの意図を優先するか判断
構造型	リファクタリングのコンフリクト	手動での書き直しが必要な場合あり

フェーズ 3: 解決戦略

目的: 各コンフリクトに最適な解決アプローチを選択する。

分析結果をユーザーに提示する:

## コンフリクト: [ファイル名]

### Ours（現在のブランチ）
[変更内容と意図のサマリー]

### Theirs（取り込みブランチ）
[変更内容と意図のサマリー]

### コンフリクトタイプ: [タイプ]

### 推奨される解決方法: [推奨内容]

解決戦略をユーザーに確認する:

Question: "このコンフリクトをどのように解決しますか？"
Header: "戦略"
Options:
- "ours（現在のブランチ）を保持"
- "theirs（取り込みブランチ）を保持"
- "両方の変更を統合"（追加型コンフリクトに推奨）
- "手動で指定する"

フェーズ 4: 解決の実装

目的: 選択された解決戦略を適用する。

注意: 単純な git 状態コマンド（checkout --ours/--theirs, add）は、解決フェーズでは親コンテキストで直接実行してよい。これらは軽量な操作でありコンテキストを消費しない。フェーズ 1〜2 の委任要件は分析コマンド（diff, status, log）にのみ適用される。

「ours を保持」の場合:

git checkout --ours <file>
git add <file>

「theirs を保持」の場合:

git checkout --theirs <file>
git add <file>

「両方を統合」の場合:

重要: code-architect は読み取り専用（Write/Edit ツールなし）。実装は適切なスペシャリストに委任すること。

適切なスペシャリストエージェント（frontend-specialist または backend-specialist）に委任:

タスク: コンフリクト解決 - 両バージョンの統合
ファイル: [コンフリクトファイルパス]

Ours バージョン:
[ours のコード]

Theirs バージョン:
[theirs のコード]

要件:
- 両方の変更の機能を保持する
- 論理的なコンフリクトを解決する
- コードスタイルの一貫性を維持する
- すべてのコンフリクトマーカー（<<<<<<< / ======= / >>>>>>>）を除去する
- 編集後にファイルをステージングする（git add）

出力: コンフリクトマーカーが除去されたマージ済みファイルの確認

スペシャリストエージェントのエラーハンドリング: スペシャリストエージェントが失敗またはタイムアウトした場合:

1. 部分的な出力に使用可能なマージコードがないか確認する
2. スコープを簡略化して1回リトライする（一度に1つのコンフリクト領域）
3. リトライも失敗した場合:

   Question: "自動マージに失敗しました。どのように進めますか？"
   Header: "マージ失敗"
   Options:
   - "両方のバージョンを表示して手動でマージする"
   - "別のアプローチでマージをリトライする"
   - "一旦 ours を保持する（後で手動対応が必要）"
   - "一旦 theirs を保持する（後で手動対応が必要）"
   

4. ユーザーが「両方のバージョンを表示」を選択した場合、ours/theirs の内容を表示し、ユーザーがマージコードを提供するのを待つ

スペシャリストエージェント完了後:

• コンフリクトマーカーが除去されていることを確認する
• 解決済みファイルをステージングする: git add <file>
• TodoWrite の項目を完了としてマークする

フェーズ 5: 検証

目的: 解決が機能を壊していないことを確認する。

重要: エージェントの能力に応じて検証を分割すること。

ステップ 1: verification-specialist でマーカーチェックを起動（読み取り専用）:

verification-specialist エージェントを起動:
タスク: コンフリクトマーカーの除去を確認
入力:
  - 解決済みファイル: [フェーズ 4 のリスト]
チェック:
  1. コンフリクトマーカーが残っていないこと（<<<<<<< / ======= / >>>>>>>）
  2. ファイル構文が妥当であること（構造分析）
出力:
  - マーカーチェックステータス（PASS/FAIL）
  - FAIL の場合: 残存マーカーの file:line 位置
Thoroughness: quick

ステップ 2: qa-engineer で実行ベースの検証を起動（Bash 使用可能）:

qa-engineer エージェントを起動:
タスク: 解決済みファイルの検証コマンドを実行
入力:
  - 解決済みファイル: [フェーズ 4 のリスト]
実行:
  1. リンター（npm run lint / eslint 等）
  2. 型チェック（tsc --noEmit 等）（該当する場合）
  3. テスト（npm test / pytest 等）
出力:
  - 各チェックの実行ステータス（PASS/FAIL）
  - FAIL の場合: file:line 付きの具体的なエラー詳細
  - 総合判定（VERIFIED / ISSUES_FOUND）

注意: verification-specialist は Bash コマンドを実行できない。lint/type/test の実行には qa-engineer を使用すること。

エージェントの出力を検証結果として使用する。親コンテキストで lint/test コマンドを直接実行しないこと。

verification-specialist が問題を報告した場合:

• どのチェックが失敗したかを提示する
• ユーザーに対応方法を確認する:

  Question: "検証で問題が見つかりました。どのように進めますか？"
  Header: "問題"
  Options:
  - "問題を修正して再検証する"
  - "まず詳細を確認する"
  - "元に戻してコンフリクトを再解決する"
  

フェーズ 6: 完了

目的: マージを確定し、解決内容を記録する。

マージ状態の確認:

git status

すべてのコンフリクトが解決された場合:

Question: "すべてのコンフリクトが解決・検証されました。どのように進めますか？"
Header: "完了"
Options:
- "merge/rebase を続行する"（推奨）
- "最終 diff を先に確認する"
- "手動で完了する"

マージの完了:

# merge の場合
git merge --continue

# rebase の場合
git rebase --continue

# cherry-pick の場合
git cherry-pick --continue

フェーズ 7: サマリーレポート

目的: 解決内容と方法を記録する。

## マージコンフリクト解決サマリー

### 操作: [merge/rebase/cherry-pick]
### ブランチ: [現在] <- [取り込み]

### 解決済みファイル

| ファイル | コンフリクトタイプ | 解決方法 | 検証結果 |
|----------|---------------------|----------|----------|
| `path/file1.ts` | 追加型 | 両方を統合 | テスト合格 |
| `path/file2.ts` | 修正型 | theirs を保持 | リント合格 |

### 解決の判断

#### file1.ts
- **コンフリクト**: 両ブランチがインポートを追加
- **解決方法**: 両方のインポートセットを保持し、重複を除去
- **理由**: 両方のインポートがそれぞれの機能に必要

#### file2.ts
- **コンフリクト**: 異なるバリデーションロジック
- **解決方法**: theirs を使用（より包括的）
- **理由**: theirs の方が追加のエッジケースを含む

### 検証結果

- [ ] コンフリクトマーカーが残っていないこと
- [ ] リント合格
- [ ] 型チェック合格
- [ ] テスト合格

### 次のステップ

1. マージされた変更をレビューする
2. フルテストスイートを実行する
3. 準備ができたらプッシュする

---

コンフリクト解決パターン

パターン 1: インポートのコンフリクト

<<<<<<< HEAD
import { AuthService } from './auth';
import { UserService } from './user';
=======
import { AuthService } from './auth';
import { LogService } from './log';
>>>>>>> feature-branch

解決方法: インポートを統合し、重複を除去:

import { AuthService } from './auth';
import { UserService } from './user';
import { LogService } from './log';

パターン 2: 関数修正のコンフリクト

両ブランチが同じ関数を異なる方法で修正した場合。両方の意図を理解し、統一された実装を作成する必要がある。

パターン 3: 削除 vs 修正

一方がコードを削除し、他方が修正した場合。どちらの意図を優先するかユーザーに確認する。

---

ルール（L1 - ハード）

• MUST: 解決後にコンフリクトマーカーが残っていないことを確認する
• NEVER: 両サイドを理解せずに自動解決する
• MUST: マージ完了前に検証を実行する
• NEVER: 共有ブランチでコンフリクト解決後に強制プッシュする

デフォルト（L2 - ソフト）

• 両バージョンの理解には並列エージェント分析を使用する
• 各コンフリクト解決後すぐにファイルをステージングする
• 最低限の検証としてリントと型チェックを実行する
• 複雑なコンフリクトの解決判断を記録する

ガイドライン（L3）

• consider: 単純なコンフリクトから先に解決してコンテキストを構築する
• prefer: 可能な場合は一方を選択するよりも変更の統合を行う
• consider: 複雑な意味的コンフリクトの場合はオリジナルの作成者に確認する
• recommend: 重要なコードパスにはフルテストスイートを実行する