Agent Merge Conflict Arbiter

2 つのエージェント間で起きたマージ衝突を、中立の立場で裁定します。

skill の情報

参考: SKILL.md 全文

Agent Merge-Conflict Arbiter

2 つのエージェントのブランチ間で起きた git のマージ衝突を、公平な第三者として 解決します。相手のエージェントの成果と衝突したとき、エージェントは決まって 相手を上書きするか、自分の変更を捨てるかのどちらかに寄ります。相手側の文脈を 持たないうえ、自分の側に肩入れしてしまうからです。この skill はそこを直します。 両方の差分と、双方が何を意図していたかを受け取って、マージキューの裁定役の ように統合結果を作る、中立の調停役です。

使いどころ

• 並行して進めているキャンペーン（かんばん方式の開発パイプライン、並列 PR の波、

複数 worktree でのリファクタリング）で、2 つのエージェントのブランチや worktree がぶつかったとき。

• git merge や git rebase が 2 つのエージェントの成果の衝突で止まり、

どちらの当事者にも自分で裁かせたくないとき。

• 1 つのエージェントが自分の作業内で起こした衝突や、ロックファイル・自動生成

ファイルの些細な衝突には使わないでください（そちらは作り直すのが筋です）。

前提

• 止まったマージを含むリポジトリのチェックアウト、または 2 つのブランチ名と、

自分でマージを実行してよいという許可。

• 双方の意図がわかる材料。かんばんの完了サマリー（terminal から

hermes kanban show <task-id> を実行）、PR 本文、少なくとも各ブランチの コミットメッセージのいずれか。

• プロジェクトにビルド／テストのコマンドがあるなら、それ。

走らせ方

単独で動かす — 衝突しているリポジトリの中で、人間（またはエージェント）が この skill を呼び出します。skill を読み込んだら、手順を上から順にたどります。

中立のエージェントを立てる — 複数エージェントのキャンペーンではこちらが おすすめの形です。

• delegate_task: サブエージェントを立て、そのタスクメッセージにリポジトリの

パス、両方のブランチ名、双方の意図のまとめをそのまま書き、あわせてこの skill に従うよう指示します。

• かんばんで完結させる形: 第三のプロファイル（どちらの作業者のものでもない

プロファイル）を担当にした調停用のカードを作り、衝突している 2 枚のカードを 両方とも親としてつなぎます — kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])。親のつながりが双方の完了サマリーを調停役の文脈へ 自動で運んでくれます。カード本文にはリポジトリのパスと 2 つのブランチ名を 書いておきます。

早見表

中立であるための約束: 自分を呼び出した側に肩入れしないこと、衝突している箇所 だけに手を入れること（ついでの修正はしない）、設計上の問いへの選択はすべて 引き渡しのサマリーに明記すること。

手順

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 本文、あるいは上のログに出てくる コミットメッセージ。ファイルに触る前に、片方につき 1 文で意図を書き出します。

• 完了の目安: 双方の意図を自分の言葉で言えて、衝突した全ファイルの差分が

手元にある。

2. 衝突箇所をひとつ残らず分類する

• 衝突した各ファイルを read_file で開き、<<<<<<</=======/>>>>>>> の

ブロックを 1 つずつ見つけます。

• 述べられた意図を基準に、早見表の種類をちょうど 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 つの種類と見なすと、両立できたはずの変更が黙って こぼれ落ちます。

• ついでの修正 はマージをレビュー不能にし、元のエージェントから判断を

奪います。

• 意図が足りない: コミットメッセージだけでは薄いことがあります。かんばんの

完了サマリーや PR 本文を優先してください。どちらの意図も取り戻せないなら、 当てずっぽうで決めずに上へ上げます。

• 常習の衝突箇所: 同じファイルで何度も衝突が起きるなら、それは日常的な

調停作業ではなく、そのファイルが火種になっている合図です。旗を立てて （たとえば hotspot: <path> — <reason> というかんばんのコメントで）、 新しい衝突のたびに延々と調停するのではなく、そのファイルを分割するよう オーケストレーター側に促してください。

検証

• git status が、対象ブランチにマージコミットがあり作業ツリーがきれいな状態を

示している。

• 衝突マーカーが残っていない（search_files でパターン <<<<<<<）。
• ビルド／テストが通り、双方の意図が実際に確認できる。落としたものがあるなら、

サマリーにその名前が明記されている。

• 引き渡しのサマリーに、すべての箇所が種類と根拠つきで並んでいる。