--- license: "MIT. Translation of the Hermes Agent documentation, Copyright (c) 2025 Nous Research. See https://wiki.winsmux.dev/hermes/licenses.txt" title: "Agent Merge Conflict Arbiter — 2 つのエージェント間のマージ衝突を中立に裁定する" description: "2 つのエージェント間のマージ衝突を中立に裁定する" upstream_path: user-guide/skills/optional/autonomous-ai-agents/autonomous-ai-agents-agent-merge-conflict-arbiter.md upstream_blob: 37c48f7f5a7acea149948ef2541504d3c09136ad sources: - https://hermes-agent.nousresearch.com/docs/user-guide/skills/optional/autonomous-ai-agents/autonomous-ai-agents-agent-merge-conflict-arbiter --- # Agent Merge Conflict Arbiter {#agent-merge-conflict-arbiter} 2 つのエージェント間で起きたマージ衝突を、中立の立場で裁定します。 ## skill の情報 {#skill-metadata} | | | |---|---| | 提供元 | 追加インストール — `hermes skills install official/autonomous-ai-agents/agent-merge-conflict-arbiter` で入れます | | パス | `optional-skills/autonomous-ai-agents/agent-merge-conflict-arbiter` | | バージョン | `1.0.0` | | 作者 | Hermes Agent | | ライセンス | MIT | | 対応プラットフォーム | linux, macos, windows | | タグ | `Multi-Agent`, `Git`, `Merge-Conflict`, `Kanban`, `Arbitration` | | 関連 skill | [`hermes-agent`](/hermes/docs/user-guide/skills/bundled/autonomous-ai-agents/autonomous-ai-agents-hermes-agent/) | ## 参考: SKILL.md 全文 {#reference-full-skillmd} :::info 以下は、この skill が呼び出されたときに Hermes が読み込む定義の全文です。skill が有効なあいだ、エージェントはこれを指示として受け取ります。 ::: # Agent Merge-Conflict Arbiter {#agent-merge-conflict-arbiter} 2 つのエージェントのブランチ間で起きた git のマージ衝突を、公平な第三者として解決します。相手のエージェントの成果と衝突したとき、エージェントは決まって相手を上書きするか、自分の変更を捨てるかのどちらかに寄ります。相手側の文脈を持たないうえ、自分の側に肩入れしてしまうからです。この skill はそこを直します。両方の差分と、双方が何を意図していたかを受け取って、マージキューの裁定役のように統合結果を作る、中立の調停役です。 ## 使いどころ {#when-to-use} - 並行して進めているキャンペーン（かんばん方式の開発パイプライン、並列 PR の波、複数 worktree でのリファクタリング）で、2 つのエージェントのブランチや worktree がぶつかったとき。 - `git merge` や `git rebase` が 2 つのエージェントの成果の衝突で止まり、どちらの当事者にも自分で裁かせたくないとき。 - 1 つのエージェントが自分の作業内で起こした衝突や、ロックファイル・自動生成ファイルの些細な衝突には使わないでください（そちらは作り直すのが筋です）。 ## 前提 {#prerequisites} - 止まったマージを含むリポジトリのチェックアウト、または 2 つのブランチ名と、自分でマージを実行してよいという許可。 - 双方の意図がわかる材料。かんばんの完了サマリー（`terminal` から `hermes kanban show ` を実行）、PR 本文、少なくとも各ブランチのコミットメッセージのいずれか。 - プロジェクトにビルド／テストのコマンドがあるなら、それ。 ## 走らせ方 {#how-to-run} **単独で動かす** — 衝突しているリポジトリの中で、人間（またはエージェント）がこの skill を呼び出します。skill を読み込んだら、手順を上から順にたどります。 **中立のエージェントを立てる** — 複数エージェントのキャンペーンではこちらがおすすめの形です。 - `delegate_task`: サブエージェントを立て、そのタスクメッセージにリポジトリのパス、両方のブランチ名、双方の意図のまとめをそのまま書き、あわせてこの skill に従うよう指示します。 - かんばんで完結させる形: **第三のプロファイル**（どちらの作業者のものでもないプロファイル）を担当にした調停用のカードを作り、衝突している 2 枚のカードを両方とも親としてつなぎます — `kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])`。親のつながりが双方の完了サマリーを調停役の文脈へ自動で運んでくれます。カード本文にはリポジトリのパスと 2 つのブランチ名を書いておきます。 ## 早見表 {#quick-reference} | 衝突箇所の種類 | 意味 | 解決のしかた | |---|---|---| | disjoint-intent | 2 つの変更が別々の目的を持っていて、両立できる | 両方を取り込む | | same-question-different-answer | 1 つの設計上の問いに、双方が別の答えを出した | 述べられた意図に沿って片方だけを選び、その判断を表に出す | | superseded | 片方の変更によって、もう片方の前提が成り立たなくなった | 生き残った側を残し、理由を書き添える | 中立であるための約束: 自分を呼び出した側に肩入れしないこと、衝突している箇所だけに手を入れること（ついでの修正はしない）、設計上の問いへの選択はすべて引き渡しのサマリーに明記すること。 ## 手順 {#procedure} ### 1. 双方の材料をそろえる {#1-gather-both-sides} - `terminal` から実行します。`git status`（衝突している状態を確かめ、衝突したファイルを一覧する）、`git merge-base `、そして衝突した各ファイルについて、双方の側で `git log --oneline ..` と `git diff .. -- `。止まったマージでは、`HEAD` が片方、 `MERGE_HEAD` がもう片方です。 - それぞれの意図を集めます。完了サマリーやメタデータなら `hermes kanban show `、あるいは PR 本文、あるいは上のログに出てくるコミットメッセージ。ファイルに触る前に、片方につき 1 文で意図を書き出します。 - 完了の目安: 双方の意図を自分の言葉で言えて、衝突した全ファイルの差分が手元にある。 ### 2. 衝突箇所をひとつ残らず分類する {#2-classify-every-conflicted-hunk} - 衝突した各ファイルを `read_file` で開き、`<<<<<<<`/`=======`/`>>>>>>>` のブロックを 1 つずつ見つけます。 - 述べられた意図を基準に、早見表の種類をちょうど 1 つずつ割り当てます。どちらの変更がきれいに見えるか、では決めません。 - 1 つの箇所に独立した判断が複数含まれているなら（たとえば、きれいに統合できる新しいロジックに加えて、書き方や丸め方の選択で双方の答えが割れている場合）、小さな判断に分解して、それぞれを分類します。 - 1 つのファイルの中で種類が混ざることはよくあります。ある箇所は設計の衝突で、隣の箇所は両立できる、という具合です。ファイル単位ではなく箇所単位で分類してください。 - 完了の目安: すべての箇所に、書き出された種類と 1 行の根拠がついている。 ### 3. 中立の約束のもとで解決する {#3-resolve-under-the-impartiality-contract} - 各箇所を `patch` で直します（ファイルごと書き直すなら `write_file`）。 - disjoint-intent → 双方の意図がどちらも満たされるように両方の変更を統合します。 - same-question-different-answer → 述べられた意図をいちばんよく満たす答えを選びます（たとえば「厳密に検証する」という意図は、課題が正しさを求めていたのであれば「手早く既定値で済ませる」に勝ちます）。どちらも求めていない折衷案でお茶を濁してはいけません。 - superseded → 生き残った側を残し、成り立たなくなった前提は削ります。 - 自分を呼び出した側に肩入れしないこと。意図が本当に互角なら、当てずっぽうで決めずに上へ上げます（かんばんのカードをブロックする、報告して戻す）。 - 衝突マーカーの外は一切変えないでください。整形も、名前の変更も、ついでの修正もしません。 - 解決したファイルは `terminal` から `git add` します。 - 完了の目安: `search_files` でリポジトリ内に `<<<<<<<` のマーカーが 1 つも見つからず、解決したファイルがすべてステージされている。 ### 4. 確かめる {#4-verify} - プロジェクトのビルド／テストを `terminal` から実行します。少なくとも、触ったモジュールを読み込むか動かしてみてください。統合後のふるまいに、双方の意図がどちらも現れている必要があります（たとえば A 側の新しい意味づけと、B 側の独立した追加が、両方そこにある）。 - マージを完了させます。`git commit`（既定のマージメッセージに、箇所ごとの判断を並べた本文を添えれば十分です）。 - 完了の目安: 検証が通り、マージコミットができている。 ### 5. 引き渡す {#5-hand-back} - すべての箇所の判断を並べた完了サマリーを作ります。 `file:lines — class — which side(s) kept — rationale` の形です。 same-question-different-answer の箇所については、設計上の問いと自分が選んだ答えを書き、人間が拒否権を使えるようにします。設計の判断を埋もれさせないでください。 - かんばんなら `kanban_complete(summary=...)`。単独で動かしたなら、サマリーを出力します。 - 完了の目安: サマリーを渡し終えていて、すべての箇所が載っている。 ## つまずきやすいところ {#pitfalls} - **自分の側に肩入れしてしまう**: 衝突している当事者のどちらかに呼び出されたのなら、構造として偏っています。そのことを明言し、相手側の意図を意識して重く見てください。そもそもこれが起きないよう、第三のプロファイルを立てる形が望ましいです。 - 設計の衝突で **折衷案に逃げる** と、誰も設計していない混ぜものができあがります。片方の答えを選び、それを表に出してください。 - **ファイル単位で分類する**: ファイルの中では種類が混ざるのが普通です。ファイルまるごとを 1 つの種類と見なすと、両立できたはずの変更が黙ってこぼれ落ちます。 - **ついでの修正** はマージをレビュー不能にし、元のエージェントから判断を奪います。 - **意図が足りない**: コミットメッセージだけでは薄いことがあります。かんばんの完了サマリーや PR 本文を優先してください。どちらの意図も取り戻せないなら、当てずっぽうで決めずに上へ上げます。 - **常習の衝突箇所**: 同じファイルで何度も衝突が起きるなら、それは日常的な調停作業ではなく、そのファイルが火種になっている合図です。旗を立てて（たとえば `hotspot: — ` というかんばんのコメントで）、新しい衝突のたびに延々と調停するのではなく、そのファイルを分割するようオーケストレーター側に促してください。 ## 検証 {#verification} - `git status` が、対象ブランチにマージコミットがあり作業ツリーがきれいな状態を示している。 - 衝突マーカーが残っていない（`search_files` でパターン `<<<<<<<`）。 - ビルド／テストが通り、双方の意図が実際に確認できる。落としたものがあるなら、サマリーにその名前が明記されている。 - 引き渡しのサマリーに、すべての箇所が種類と根拠つきで並んでいる。