Merge Reconciler: Neutral Third-Party Git Conflict Resolution for Agents
Neutral third-party resolution of agent merge conflicts.
Written by Neura Market from the official Hermes Agent documentation for Merge Reconciler. Commands, paths, and version numbers are reproduced from the source unchanged.
Read the official documentationWhen two autonomous agents work on parallel branches and their changes collide, the merge often stalls. Each agent, left to resolve the conflict itself, tends to favor its own work or overwrite the peer's, because it lacks the other's context. The Merge Reconciler skill solves this by acting as an impartial arbiter: it takes both diffs and both sides' stated intents, classifies every conflicted hunk, and produces a merged result that honors both goals. You would reach for this when you need a fair, auditable resolution that neither original agent should perform.
What it does
The skill turns a halted git merge or git rebase into a structured reconciliation process. Instead of letting one side win by default, it forces a neutral party to gather both branches' changes and their intent summaries, then classify each conflict into one of three hunk classes: disjoint-intent, same-question-different-answer, or superseded. For each class, it prescribes a resolution: combine both changes, pick one answer per the stated intents, or keep the surviving side. The reconciler must touch only the conflicted regions, never make drive-by edits, and explicitly report every design decision in the hand-back summary so a human can veto it. This makes the merge reviewable and keeps the original agents' ownership intact.
Before you start
You need a repository checkout that contains the halted merge, or the two branch names plus permission to run the merge yourself. You also need both sides' intent sources: kanban completion summaries (via hermes kanban show), PR bodies, or at minimum each branch's commit messages. If the project has a build or test command, have it ready for verification. The skill is bundled with Hermes Agent (installed by default) and works on linux, macos, and windows. It is version 1.0.0, authored by Hermes Agent, and released under the MIT license.
How to run it
You can invoke the skill in two ways. Standalone, a human or agent loads the skill inside the conflicted repo and follows the Procedure top to bottom. In multi-agent campaigns, the preferred shape is to spawn a neutral agent: use delegate_task with a task message containing the repo path, both branch names, and both sides' intent summaries verbatim, plus an instruction to follow this skill. Alternatively, use the kanban-native approach: create a reconciliation card assigned to a third profile (not either worker's profile) with both conflicted cards linked as parents, like 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
The skill defines three hunk classes. Use this table to classify every conflict:
| 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 is non-negotiable: 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
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.
Done 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 (e.g., new logic that combines cleanly PLUS a styling/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.
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.
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/execute the 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).
Complete the merge: git commit (the default merge message plus a body listing hunk decisions is fine).
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.
Kanban: kanban_complete(summary=...). Standalone: print the summary.
Done when: the summary is delivered and lists all hunks.
When not to use it
Do NOT use this skill for conflicts within a single agent's own work, or for trivial lockfile/generated-file conflicts. Those are better handled by regenerating the files rather than reconciling them. The skill is designed for collisions between two agents' branches during parallel campaigns, not for routine merge chores.
Limits and gotchas
Several pitfalls can undermine a reconciliation. Self-favoring is the most insidious: if you were spawned by one of the conflicting agents, you are structurally biased. State this and weigh the other side's intent deliberately; prefer the third-profile shape 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 trap: files usually mix hunk classes, so classifying a whole file as one class silently drops a disjoint change. Drive-by edits make the merge unreviewable and steal decisions from the original agents. Missing intents are another risk: commit messages alone can be thin; prefer kanban completion summaries or PR bodies. If neither side's intent is recoverable, escalate instead of guessing. Finally, repeated conflicts on the SAME file across rounds are a hotspot signal, not routine reconciliation work. Flag it (e.g. a hotspot:, kanban comment) so the orchestrator decomposes that file, rather than serially reconciling every new collision on it.
Verification
After following the procedure, confirm the outcome with these checks: 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.
Related skills
This skill pairs with hermes-agent, the core skill that orchestrates autonomous agent workflows. Use it as part of a larger multi-agent pipeline where parallel branches and kanban cards are the norm.