merge-reconciler

マージリコンシリエーター

2 つのエージェントのブランチ間で発生した Git のマージコンフリクトを、第三者として中立的に解決します。競合を解決するエージェントは、相手の作業を上書きするか、自分の変更を諦めるかのどちらかになりがちです。相手の背景を把握しておらず、自分側に偏ってしまうためです。このスキルは、その問題を解決します。両方の差分と、それぞれが表明した意図を受け取り、マージキューの調停役のように、マージ後の結果を生成する中立的なリコンシリエーターです。

使用するタイミング

• 並行キャンペーン（カンバン形式のエンジニアリングパイプライン、並行 PR の一斉対応、複数ワークツリーでのリファクタリング）中に、2 つのエージェントのブランチ／ワークツリーが衝突した場合。
• 2 つのエージェントの作業間でコンフリクトが発生して git merge または git rebase が停止し、元のエージェントのどちらにも自分で裁定させるべきではない場合。
• 1 つのエージェント自身の作業内でのコンフリクトや、単純なロックファイル／生成ファイルのコンフリクトには使用しないでください（その場合は再生成してください）。

前提条件

• マージが停止したリポジトリのチェックアウト、または 2 つのブランチ名と、自分でマージを実行する権限があること。
• 両側の意図を示す情報源：カンバンの完了サマリー（terminal で hermes kanban show <task-id> を実行）、PR の説明文、または最低限、各ブランチのコミットメッセージ。
• プロジェクトのビルド／テストコマンド（存在する場合）。

実行方法

単独で実行 — 人間（またはエージェント）がコンフリクトのあるリポジトリ内でこのスキルを呼び出します。スキルを読み込んだ後、手順に上から順に従ってください。

中立なエージェントを起動 — マルチエージェントキャンペーンでは、この方法を推奨します。

• delegate_task：リポジトリのパス、両方のブランチ名、両側の意図のサマリー（原文のまま）を含むタスクメッセージでサブエージェントを起動し、このスキルに従うよう指示します。
• カンバンを使用する場合：第三のプロファイル（どちらの作業者のプロファイルでもない）に割り当てた調整カードを作成し、コンフリクトしている両方のカードを親としてリンクします — kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])。親リンクにより、両側の完了サマリーが自動的にリコンシリエーターのコンテキストに取り込まれます。カードの本文には、リポジトリのパスと 2 つのブランチ名を記載してください。

クイックリファレンス

ハンクの種類	定義	解決方法
disjoint-intent	2 つの変更が異なる目的に役立ち、共存できる	両方を組み合わせる
same-question-different-answer	両側が、ある設計上の問いに異なる答えを示している	表明された意図に基づき、どちらか 1 つを選び、判断内容を明示する
superseded	片側の変更によって、もう片側の前提が成り立たなくなっている	残る側を採用し、その理由を記す

公平性の約束：自分を起動した側を決して優先しないこと。コンフリクト領域だけを変更すること（ついでの編集はしないこと）。設計上の問いに対する選択は、すべて引き継ぎサマリーに明示すること。

手順

1. 両側の情報を集める

• terminal で次を実行します：git status（コンフリクト状態を確認し、コンフリクトしているファイルを列挙）、git merge-base <A> <B>、続いて各側について git log --oneline <base>..<side> と、コンフリクトしているすべてのファイルに対する git diff <base>..<side> -- <file>。マージが停止している場合、HEAD が一方の側で、もう一方が MERGE_HEAD です。
• 各側の意図を収集します：完了サマリー／メタデータは hermes kanban show <task-id>、または PR の説明文、または上記ログのコミットメッセージを使います。ファイルに触れる前に、各側の意図を一文で書き留めてください。
• 完了条件：両側の意図を自分の言葉で説明でき、コンフリクトしているすべてのファイルについて、両側の差分を確認できていること。

2. 競合したすべてのハンクを分類する

• read_file で競合している各ファイルを開き、それぞれの <<<<<<</=======/>>>>>>> ブロックを特定します。
• 各ハンクに、クイックリファレンス表からちょうど 1 つのクラスを割り当てます。判断は 明示された意図に基づいて行い、どちらの変更がより良く見えるかで判断してはいけません。
• 1 つのハンクに複数の独立した決定が含まれる場合（例: きれいに統合できる新しいロジック に加えて、両側が異なる答えを出したスタイリング/丸めの選択がある場合）、それを サブ決定に分解し、それぞれを分類します。
• 1 つのファイルはしばしば複数のクラスが混在します。あるハンクは設計の衝突である一方、 隣のハンクは無関係かもしれません。ファイル単位ではなくハンク単位で分類します。
• 完了条件: すべてのハンクに記載されたクラスと 1 行の根拠があること。

3. 公平性契約のもとで解決する

• patch で各ハンクを編集します（ファイル全体の書き換えには write_file を使用）:
  • disjoint-intent → 両方の変更をマージし、それぞれの意図が完全に満たされるようにします。
  • same-question-different-answer → 明示された意図に最もよくかなう答えを選びます （例: タスクが正確性を要求していた場合、「厳格な検証」という意図は「手早い デフォルト」に勝ります）。どちらの側も求めていないハイブリッドに妥協して 分割してはいけません。
  • superseded → 存続する側を保持し、死んだ前提を削除します。
• 自分を生み出した側を決して優遇してはいけません。意図が本当に拮抗している場合は、 推測するのではなくエスカレーションします（カンバンカードをブロックする / 報告する）。
• 競合マーカーの外側は何も変更しません — フォーマット、リネーム、便宜的な修正も行いません。
• terminal 経由で解決済みの各ファイルを git add します。
• 完了条件: search_files がリポジトリ内に <<<<<<< マーカーを 1 つも見つけず、解決済みの すべてのファイルがステージされていること。

4. 検証する

• terminal 経由でプロジェクトのビルド/テストを実行します。最低限、触れたモジュールを インポート/実行します。両方の意図がマージ後の動作で観察できなければなりません （例: 側 A の新しいセマンティクスと側 B の無関係な追加の両方が存在すること）。
• マージを完了します: git commit（デフォルトのマージメッセージに加えて、ハンクの決定を 列挙した本文で問題ありません）。
• 完了条件: 検証がパスし、マージコミットが存在すること。

5. 引き渡す

• すべてのハンクの決定を列挙した完了サマリーを作成します: file:lines — class — which side(s) kept — rationale。すべての same-question-different-answer ハンクについて、設計上の問いと選んだ答えを明記し、 人間がそれを否决できるようにします — 設計上の判断を決して埋もれさせてはいけません。
• カンバン: kanban_complete(summary=...)。スタンドアロン: サマリーを出力します。
• 完了条件: サマリーが配信され、すべてのハンクを列挙していること。

落とし穴

• 自己優遇: 競合しているエージェントの 1 つから自分が生み出された場合、あなたは 構造的に偏っています — このことを明言し、もう一方の側の意図を意図的に重み付けします。 これが決して起こらないように、サードプロファイルの形を優先します。
• 設計の衝突で妥協して分割すると、誰も設計していないハイブリッドが生まれます。 1 つの答えを選び、それを明示します。
• ファイル単位の分類: ファイルは通常ハンクのクラスが混在します。ファイル全体を 1 つのクラスとして分類すると、無関係な変更を黙って落としてしまいます。
• ついでの編集はマージをレビュー不能にし、元のエージェントから決定を奪います。
• 意図の欠落: コミットメッセージだけでは薄いことがあります。カンバンの完了 サマリーや PR 本文を優先します。どちらの側の意図も回復できない場合は、推測せずに エスカレーションします。
• 繰り返す問題: ラウンドをまたいで同じファイルで繰り返される競合は、通常の 調整作業ではなくホットスポットのシグナルです — それをフラグ付けします（例: hotspot: <path> — <reason> というカンバンコメント）。そうすることでオーケストレーターが そのファイルを分解でき、新しい衝突のたびに逐次調整する必要がなくなります。

検証

• git status が、対象ブランチ上でマージコミットを伴うクリーンなツリーを示す。
• 競合マーカーが残っていない（search_files のパターン <<<<<<<）。
• ビルド/テストがパスする。両方の側の意図が実証可能に存在するか、落とされた側が サマリーで明示的に名指しされている。
• 引き渡しサマリーが、すべてのハンクをクラスと根拠とともに列挙している。