agent-merge-conflict-arbiter skill

Agent Merge-Conflict Arbiter

Resolve a git merge conflict between two AGENTS' branches as an impartial third party. Agents resolving conflicts against a peer's work reliably either overwrite the peer or abandon their own change — they lack the peer's context and are biased toward their own side. This skill is the fix: a neutral reconciler that receives both diffs plus both sides' stated intents and produces a merged result, like a merge-queue arbiter.

When to Use

engineering pipeline, parallel-PR wave, multi-worktree refactor).

• Two agent branches/worktrees collide during a parallel campaign (kanban

neither original agent should self-adjudicate.

• git merge or git rebase halts on conflicts between two agents' work and

lockfile/generated-file conflicts (regenerate those instead).

• Do NOT use for conflicts within a single agent's own work, or for trivial

Prerequisites

permission to run the merge yourself.

• A repo checkout containing the halted merge, or the two branch names plus

hermes kanban show ), PR bodies, or at minimum each branch's commit messages.

• Both sides' intent sources: kanban completion summaries (terminal running

• The project's build/test command, if one exists.

How to Run

Standalone — a human (or agent) invokes this skill inside the conflicted repo: load the skill, then follow the Procedure top to bottom.

Spawned neutral agent — the preferred shape in multi-agent campaigns:

both branch names, and both sides' intent summaries verbatim, plus an instruction to follow this skill.

• delegate_task: spawn a subagent whose task message contains the repo path,

(not either worker's profile) with BOTH conflicted cards linked as parents — kanbancreate(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["ta", "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.

• Kanban-native: create a reconciliation card assigned to a third profile

Quick Reference

Impartiality contract: never favor the side that spawned you; touch ONLY conflicted regions (no drive-by edits); every design-question pick must appear explicitly in the hand-back summary.

Procedure

1. Gather both sides

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.

• Run via terminal: git status (confirm the conflicted state and list

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.

• Collect each side's intent: hermes kanban show for completion

for every conflicted file.

• Done when: you can state both intents in your own words and have both diffs

2. Classify every conflicted hunk

<<<<<<</=======/>>>>>>> block.

• Open each conflicted file with read_file and locate each

by the stated intents — not by which change looks nicer.

• Assign each hunk exactly one class from the Quick Reference table, judging

that combines cleanly PLUS a styling/rounding choice both sides answered differently), decompose it into sub-decisions and classify each one.

• If a single hunk contains multiple independent decisions (e.g., new logic

a neighboring hunk is disjoint. Classify per hunk, not per file.

• A single file often mixes classes: one hunk may be a design collision while

• Done when: every hunk has a written class and a one-line rationale.

3. Resolve under the impartiality contract

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.

• 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

(block the kanban card / report back) rather than guess.

• superseded → keep the surviving side; delete the dead premise.
• Never favor the side that spawned you. If intents genuinely tie, escalate

opportunistic fixes.

• Change nothing outside conflict markers — no formatting, renames, or

resolved file is staged.

• git add each resolved file via terminal.
• Done when: search_files finds no <<<<<<< markers in the repo and every

4. Verify

touched modules. Both intents must be observable in the merged behavior (e.g., side A's new semantics AND side B's disjoint addition both present).

• Run the project's build/tests via terminal; at minimum import/execute the

listing hunk decisions is fine).

• Complete the merge: git commit (the default merge message plus a body

• Done when: verification passes and the merge commit exists.

5. Hand back

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.

• Produce a completion summary naming EVERY hunk decision: