Merge conflict resolution

Skill synaptiai/synapti-marketplace/plugins/flow/skills/merge-conflict-resolution

The Synapti Marketplace is a curated collection of Claude Code plugins designed for AI-augmented development + advanced analytical and research tasks. Each plugin provides specialized agents, skills, and commands that extend Claude Code's capabilities in specific domains.

Install

npx -y skills add synaptiai/synapti-marketplace --skill merge-conflict-resolution

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Detect, classify (porcelain status; complexity: trivial, semantic, structural, delete-modify), and resolve git merge conflicts through per-file strategy selection (accept-ours, accept-theirs, manual-merge, rebase), manual conflict hunk parsing, and post-resolution verification (orphaned markers, build, tests). Use when a branch has conflicts with its merge target or when rebasing onto an updated base. This skill MUST be consulted because silently dropping changes is non-negotiable; every conflict resolution must account for both sides.

SKILL.md

5.4 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

Merge Conflict Resolution

Domain skill for detecting, classifying, and resolving git merge conflicts systematically.

Iron Law

NEVER silently drop changes. Every conflict resolution must account for both sides. If lines from either side are excluded, the rationale must be documented. When in doubt, ask the user rather than guess.

Conflict Detection

Detect conflicted files and their conflict types:

# List files with unmerged entries
git diff --name-only --diff-filter=U

# Full status with conflict markers
git status --porcelain

Classify each file by its porcelain status prefix.

Conflict Type Classification

Status	Type	Description
UU	Content	Both sides modified the same file
AA	Add-add	Both sides added a file with the same name
UD	Delete-modify (ours deleted)	We deleted, they modified
DU	Delete-modify (theirs deleted)	They deleted, we modified
AU	Rename-related (add/unmerged)	Rename collision
UA	Rename-related (unmerged/add)	Rename collision

Conflict Complexity Classification

Assess each conflicted file's complexity before choosing a strategy:

Complexity	Description	Example
Trivial	Non-overlapping changes in different sections	Import added at top + function added at bottom
Semantic	Changes to the same logical unit	Both sides modify the same function
Structural	File was refactored on one side	Moved code, renamed variables, changed structure
Delete-modify	One side deleted what the other modified	Feature removed vs feature enhanced

Resolution Strategies

Strategy	When to Use	Risk	Autonomy
accept-ours	Their change is superseded by ours	Low	Tier 1 for trivial
accept-theirs	Our change is superseded by theirs	Low	Tier 1 for trivial
manual-merge	Both changes are needed	Medium	Tier 2 — show rationale
rebase	Clean linear history needed, few conflicts	Medium	Tier 2 — show rationale

Manual Merge Algorithm

For each conflict hunk in a file:

Parse — extract the ours block (<<<<<<< to =======) and theirs block (======= to >>>>>>>)
Identify intent — what was each side trying to accomplish?
Classify compatibility:
- Compatible: both changes can coexist (e.g., different imports, non-overlapping logic) → combine both
- Competing: changes are mutually exclusive (e.g., different implementations of the same function) → ask user
Apply — write the resolved content, removing all conflict markers
Verify — confirm no orphaned markers remain in the file

Delete-Modify Protocol

When one side deletes a file (or section) that the other side modifies:

Show the user what was deleted and what was modified
Present options:
- Keep the modified version
- Accept the deletion
- Keep modified version in a new location (if file was moved)
Wait for user decision — never auto-resolve delete-modify conflicts

Post-Resolution Verification

After resolving all conflicts, run these checks in order:

1. Orphaned Marker Audit

# Must return zero results
grep -rn '<<<<<<<\|=======\|>>>>>>>' --include='*' . 2>/dev/null | grep -v '.git/' | grep -v 'node_modules/'

If any markers remain, resolution is incomplete. Fix before proceeding.

2. Stage and Complete

# Stage resolved files
git add <resolved-files>

# Complete the merge or rebase
git merge --continue   # or git rebase --continue

3. Build and Test Verification

Run the project's quality commands (lint, test, typecheck) to verify the resolution didn't break anything. Use capability-discovery to find available commands.

4. Resolution Diff Display

Show a summary of what was resolved:

# Show what changed in the resolution
git diff HEAD~1 --stat

Rationalization Prevention

Watch for these shortcuts that lead to incorrect resolutions:

Rationalization	Correct Response
"Just take ours for everything"	Analyze each conflict individually — theirs may contain important changes
"Too complex, just reset and start over"	Read both sides first — most conflicts are simpler than they appear
"Tests pass so the resolution is correct"	Review the diff too — passing tests don't guarantee semantic correctness
"This file isn't important"	Every file in the conflict list matters — verify or explicitly document why it's safe to skip
"Same change on both sides"	Verify they're truly identical — similar-looking changes may have subtle differences