Agent Merge Conflict Arbiter: Resolve Two Agents' Git Conflicts

When two autonomous agents work in parallel and their branches collide, neither agent is a good judge of the resulting merge conflict. Each one lacks the other's context and tends to favor its own change. The Agent Merge Conflict Arbiter skill turns a third party, a human or a spawned neutral agent, into the reconciler: it takes both diffs plus both sides' stated intents and produces a merged result. Reach for it during parallel campaigns where git merge or git rebase has halted between two agents' work.

What it does

The skill gives you a repeatable procedure for adjudicating a halted merge between two agents' branches. It is not a merge tool and it does not auto-resolve anything. It is a set of instructions that a neutral party follows: gather both sides, classify every conflicted hunk, resolve under an impartiality contract, verify, and hand back a summary that names every decision.

The core idea is that conflicts between two agents fall into a small number of classes, and each class has a different correct resolution. A hunk where the two changes serve different goals can simply combine both. A hunk where both sides answered one design question differently needs a single pick, surfaced explicitly. A hunk where one side's premise no longer holds after the other's change keeps the surviving side and drops the dead premise. Classifying per hunk, rather than per file, is what keeps a disjoint change from being silently dropped next to a design collision.

Before you start

You need a repo checkout that contains the halted merge, or the two branch names plus permission to run the merge yourself. The skill assumes you can operate on the repository directly.

You also need both sides' intent sources. The preferred inputs are kanban completion summaries, PR bodies, or at minimum each branch's commit messages. Without a recoverable statement of what each side was trying to do, you cannot classify hunks by intent, and the skill tells you to escalate rather than guess.

If the project has a build or test command, have it ready. Verification depends on it.

The skill is optional and installed on demand. It lives at optional-skills/autonomous-ai-agents/agent-merge-conflict-arbiter, version 1.0.0, authored by Hermes Agent under the MIT license, and it runs on linux, macos, and windows.

How to run it

There are two shapes. In the standalone shape, a human or agent invokes the skill inside the conflicted repo: load the skill, then follow the Procedure top to bottom.

The spawned neutral agent shape is the preferred one in multi-agent campaigns. You can use delegate_task to spawn a subagent whose task message contains the repo path, both branch names, and both sides' intent summaries verbatim, plus an instruction to follow this skill. The kanban-native variant creates a reconciliation card assigned to a third profile, not either worker's profile, with both conflicted cards linked as parents:

kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])

The parent links carry both sides' completion summaries into the reconciler's context automatically. The card body should name the repo path and the two branches.

Quick reference: hunk classes

Hunk class	Definition	Resolution
disjoint-intent	The two changes serve different goals and can coexist	Combine both
same-question-different-answer	Both sides answered one design question differently	Pick ONE per stated intents; surface the decision
superseded	One side's premise no longer holds after the other's change	Keep the surviving side; note why

The impartiality contract sits alongside the table: never favor the side that spawned you, touch only conflicted regions with no drive-by edits, and make every design-question pick appear explicitly in the hand-back summary.

Procedure

1. Gather both sides

Run via terminal: git status (confirm the conflicted state and list conflicted files), git merge-base , then for each side git log --oneline .. and git diff .. -- for every conflicted file. In a halted merge, HEAD is one side and MERGE_HEAD is the other.

Collect each side's intent: hermes kanban show for completion summaries/metadata, or the PR body, or the commit messages from the log above. Write down one sentence of intent per side before touching any file.

You are done with this step when you can state both intents in your own words and have both diffs for every conflicted file.

2. Classify every conflicted hunk

Open each conflicted file with read_file and locate each >>>>>> block. Assign each hunk exactly one class from the Quick Reference table, judging by the stated intents, not by which change looks nicer.

If a single hunk contains multiple independent decisions, for example new logic that combines cleanly plus a styling or rounding choice both sides answered differently, decompose it into sub-decisions and classify each one. A single file often mixes classes: one hunk may be a design collision while a neighboring hunk is disjoint. Classify per hunk, not per file.

You are done when every hunk has a written class and a one-line rationale.

3. Resolve under the impartiality contract

Edit each hunk with patch (or write_file for whole-file rewrites):

• disjoint-intent → merge both changes so each intent is fully served.
• same-question-different-answer → pick the answer that best serves the STATED intents (e.g., an intent of "strict validation" beats "quick default" if the task required correctness). Never split the difference into a hybrid neither side asked for.
• superseded → keep the surviving side; delete the dead premise.

Never favor the side that spawned you. If intents genuinely tie, escalate (block the kanban card / report back) rather than guess. Change nothing outside conflict markers: no formatting, renames, or opportunistic fixes. git add each resolved file via terminal.

You are done when search_files finds no <<<<<<< markers in the repo and every resolved file is staged.

4. Verify

Run the project's build/tests via terminal; at minimum import or execute the touched modules. Both intents must be observable in the merged behavior, for example side A's new semantics AND side B's disjoint addition both present.

Complete the merge: git commit (the default merge message plus a body listing hunk decisions is fine).

You are done when verification passes and the merge commit exists.

5. Hand back

Produce a completion summary naming EVERY hunk decision: file:lines, class, which side(s) kept, rationale. For every same-question-different-answer hunk, state the design question and the answer you picked so a human can veto it. Never bury a design call.

On kanban, use kanban_complete(summary=...). Standalone, print the summary. You are done when the summary is delivered and lists all hunks.

When not to use it

The skill is explicit about its boundaries. Do not use it for conflicts within a single agent's own work. Do not use it for trivial lockfile or generated-file conflicts; regenerate those instead. The arbiter exists for collisions between two agents' work, where neither original agent should self-adjudicate.

Limits and gotchas

The pitfalls section is worth reading before you start, because most of them are failure modes that look like progress.

Self-favoring is the structural one. If you were spawned by one of the conflicting agents, you are biased toward that side. State this and weigh the other side's intent deliberately. The third-profile shape exists so this never arises.

Splitting the difference on a design collision produces a hybrid nobody designed. Pick one answer and surface it.

Per-file classification is a silent failure. Files usually mix hunk classes, and classifying a whole file as one class drops a disjoint change without anyone noticing.

Drive-by edits make the merge unreviewable and steal decisions from the original agents.

Missing intents are common when commit messages alone are thin. Prefer kanban completion summaries or PR bodies. If neither side's intent is recoverable, escalate instead of guessing.

Repeat offenders deserve a different response. Repeated conflicts on the SAME file across rounds are a hotspot signal, not routine reconciliation work. Flag it, for example with a hotspot:, kanban comment, so the orchestrator decomposes that file rather than serially reconciling every new collision on it.

Verification checklist

• git status shows a clean tree on the target branch with a merge commit.
• No conflict markers remain (search_files pattern <<<<<<<).
• Build/tests pass; both sides' intents are demonstrably present or the dropped one is explicitly named in the summary.
• The hand-back summary enumerates every hunk with class and rationale.

What pairs with this

The related skill listed for this one is hermes-agent. If you are running the kanban-native shape, the reconciliation card depends on the kanban tooling that carries parent completion summaries into the reconciler's context, so keep that workflow in view when you set up the third profile.