Resolve git merge conflicts intelligently after pulling or merging main. Analyzes each conflict hunk, categorizes by complexity (trivial, clear-winner, needs-human), auto-resolves what it can, and escalates complex conflicts to the user with context. Also detects semantic conflicts where code merges cleanly but logic breaks. Use this skill whenever the user mentions merge conflicts, failed merge, conflict resolution, "pulled main and got conflicts", rebase conflicts, or any situation where git reports unmerged paths.
You are resolving merge conflicts on the current branch. Your job is to analyze every conflict, resolve the ones where the right answer is clear, and present the ambiguous ones to the user with enough context that they can make a fast decision. Never commit anything — stage resolutions and present a summary for approval.
Start by understanding what happened and what you're working with.
# What merge state are we in?
git status
# Which files have conflicts?
git diff --name-only --diff-filter=U
# What branches are involved?
git log --oneline -1 HEAD
git log --oneline -1 MERGE_HEAD 2>/dev/null || git log --oneline -1 ORIG_HEAD
Read each conflicted file to find all conflict markers (<<<<<<<, =======, >>>>>>>). Count the total number of conflict hunks across all files — this gives the user a sense of scope.
Report to the user:
Found across after merging into . Analyzing each one now.
<source><branch>For every conflict hunk, determine which category it falls into. This is the most important phase — getting categorization wrong means either bothering the user unnecessarily or silently making bad choices.
The resolution is mechanical and there's only one correct answer. No judgment needed.
Examples:
Resolution approach: Merge mechanically. For imports, combine and sort. For formatting, prefer the side that matches the project's formatter config (check for .prettierrc, .editorconfig, rustfmt.toml, etc.). For identical changes, take either side.
One side's change is clearly correct and the other should yield, but it takes a small amount of reasoning to see why.
Examples:
validateUser to validateAccount and added a suspended check, while the other side added a banned check to validateUser, the result should be validateAccount with BOTH the suspended and banned checks. The rename is structural; the logic additions from both sides are independent and both matter.Resolution approach: To determine the winner, read the commit messages on both sides of the conflict. Use git log to understand the intent behind each change. When one side is clearly the right choice, take it — but note your reasoning in the summary.
Both sides made substantive changes that reflect different intentions, and combining them requires understanding the product/architecture direction.
Examples:
Resolution approach: Don't guess. Present both versions to the user with context about what each side was trying to do (from commit messages and surrounding changes). Suggest a resolution if you have a strong opinion, but make it clear it's a suggestion.
For any conflict that isn't obviously trivial, gather context before categorizing:
# What was the intent on each side?
git log --oneline MERGE_HEAD..HEAD -- <file> # Changes on current branch
git log --oneline HEAD..MERGE_HEAD -- <file> # Changes from main
# See the full diff for each side's changes to this file
git diff HEAD...<merge-source> -- <file>
Read the functions/classes surrounding the conflict — sometimes a conflict hunk looks simple in isolation but is part of a larger change that matters.
Work through conflicts in order: trivial first, then clear-winner, then needs-human.
<<<<<<<, =======, >>>>>>>)git add <file> to stage the resolutionDo NOT resolve these. Leave the conflict markers in place. Instead, build a detailed brief for the user (presented in Phase 4).
After resolving marked conflicts, look for semantic issues — places where the merge succeeded textually but the code may be broken logically.
Check for:
How to detect these:
# After resolving textual conflicts, check for obvious issues
# Run the project's type checker / compiler if available
# e.g., tsc --noEmit, cargo check, go build, python -m py_compile
# Look for duplicate function/class definitions
grep -rn "^function \|^class \|^def \|^const \|^let \|^var " <resolved-files>
# Check for dangling references to things that were removed on main
If you find semantic issues, add them to the summary as a separate section. These often need human input since they require understanding the intended behavior.
Present a clear, structured summary. This is what the user sees before anything is committed, so it needs to be scannable and actionable.
## Merge Conflict Resolution Summary
**Branch**: `feature-x` merging `main`
**Total conflicts**: N across M files
### Auto-Resolved (X conflicts)
#### Trivial (Y conflicts)
- `src/utils.ts:45` — Combined import statements from both sides
- `config.json:12` — Merged adjacent config entries
#### Clear Winner (Z conflicts)
- `src/api.ts:120` — Took main's version: function was renamed as part of the API cleanup (commit abc123)
- `src/model.ts:89` — Took branch's version: bugfix to validation logic that main's deletion would have removed
### Needs Your Input (W conflicts)
#### 1. `src/auth.ts:34-58` — Competing auth implementations
**Main's version**: Switched to JWT-based auth with refresh tokens
**Branch's version**: Added OAuth2 PKCE flow
**My suggestion**: These serve different purposes — main's JWT handles internal auth while branch's OAuth handles third-party. You likely need both, wired into a strategy pattern.
#### 2. `src/pricing.ts:15` — Conflicting threshold values
**Main's version**: `FREE_TIER_LIMIT = 1000`
**Branch's version**: `FREE_TIER_LIMIT = 5000`
**Context**: Main lowered it per commit "reduce free tier abuse", branch raised it per commit "expand free tier for launch"
**My suggestion**: This is a business decision — which direction does the team want to go?
### Semantic Issues Detected (if any)
- `src/handlers.ts:92` calls `validateUser(id)` but main renamed it to `validateAccount(id)` — needs a reference update
Ask the user to:
Once the user approves:
git addgit diff --check to confirm no conflict markers remainIf the user wants to commit, ask for their preferred commit message or suggest one that summarizes what was merged and any notable resolution decisions.