resolving-merge-conflicts
Skill11 starsChanged 3 months agoMITView on GitHub
Use when git merge or rebase fails with conflicts, you see 'unmerged paths' or conflict markers (<<<<<<< =======), or need help resolving conflicted files. Triggers: 'merge conflict', 'fix the conflicts', 'conflicting changes', 'resolve conflicts', 'can't merge'.
We split this skill into the rules it gives an agent
9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
Synthesis over selection: - Never pick sides. Create third option combining both intents.
- Very specific: line 25
Every line of code in a branch represents thought, debugging, and testing.
- Distinctive: line 27
If you cannot figure out how to synthesize, that is a signal to ask for help, not a signal to amputate.
- Distinctive: line 49
Before resolving each conflict:
- Distinctive: line 62
If removing code, what breaks?
- Distinctive: line 63
IF NO to ANY: STOP. Revise synthesis strategy.
- Distinctive: line 167
Ask binary question about complex code
- Distinctive: line 175
Only with explicit user consent after tradeoff explanation:
- Distinctive: line 211
If ANY item unchecked or synthesis test fails: STOP and fix.
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Merge Conflict Resolution
<ROLE>
Git Archaeology Expert + Code Synthesis Specialist. Reputation depends on preserving both branches' intents while creating clean, unified code.
</ROLE>Invariant Principles
- Synthesis over selection - Never pick sides. Create third option combining both intents.
--ours/--theirs= amputation. - Intent preservation - Both branches represent valuable parallel work. Understand WHY each changed before touching code.
- Surgical precision - Line-by-line edits, never wholesale replacement. >20 line changes require explicit approval.
- Evidence-based decisions - Tests exist for reasons. Deleting tested code = breaking expected behavior. Check first.
- Consent before loss - User must explicitly approve any code removal after understanding tradeoffs.
Why Synthesis Matters
Every line of code in a branch represents thought, debugging, and testing. Choosing --ours declares the other developer's work worthless. Choosing --theirs declares the current branch's work worthless. Both branches exist because both were needed.
If you cannot figure out how to synthesize, that is a signal to ask for help, not a signal to amputate.
Inputs
| Input | Required | Description |
conflict_files | Yes | List of files with merge conflicts (from git status) |
merge_base | Yes | Common ancestor commit (from git merge-base) |
ours_branch | Yes | Current branch name |
theirs_branch | Yes | Branch being merged |
Outputs
| Output | Type | Description |
resolution_plan | Inline | Per-file synthesis strategy with base/ours/theirs analysis |
resolved_files | Files | Conflict-free source files with synthesized changes |
verification_report | Inline | Test results, lint status, behavior confirmation |
Reasoning Schema
<analysis>
Before resolving each conflict:
- Merge base state: [original before divergence]
- Ours changed: [what + why]
- Theirs changed: [what + why]
- Tests covering this code: [yes/no, which ones]
- Both intents preservable: [yes/how or no/why]
</analysis><reflection>
After resolution:
- Am I synthesizing or selecting? [must be synthesizing]
- Surgical or wholesale? [must be surgical]
- User approved THIS specific change? [not extrapolated from other approval]
- If removing code, what breaks? [tests, features, behaviors]
IF NO to ANY: STOP. Revise synthesis strategy.
</reflection>Proceed only when synthesis strategy clear and surgical.
Conflict Classification
| Type | Files | Resolution |
| Mechanical | Lock files, changelogs, test fixtures | Auto: regenerate locks, chronological changelog merge |
| Binary | Images, compiled assets | Ask user to choose (synthesis impossible) |
| Complex | Source, configs, docs | 3-way analysis + synthesis required |
Resolution Workflow
- Detect: List conflicted files, classify mechanical/complex
- Analyze: 3-way diff (base vs ours vs theirs) per file
- Auto-resolve: Mechanical files only
- Plan: Synthesis strategy per complex file, present for approval
- Execute: Surgical edits after explicit approval
- Verify: Tests pass, lint clean, behavior preserved. If tests fail: do NOT declare done — identify which branch's behavior broke and revise synthesis.
Common Patterns
| Pattern | Resolution |
| Both modified same function | Merge both changes (logging AND error handling) |
| Delete vs modify | Apply modification to new location |
| Same name, different purpose | Rename to distinguish |
| Same name, same purpose | True merge into unified implementation |
Synthesis Example
Both branches modified the same validation function. Ours added rate limiting. Theirs added input sanitization.
<<<<<<< ours
function validateRequest(req) {
if (rateLimiter.isExceeded(req.ip)) {
throw new RateLimitError('Too many requests');
}
return processRequest(req);
}
=======
function validateRequest(req) {
const sanitized = sanitizeInput(req.body);
return processRequest({ ...req, body: sanitized });
}
>>>>>>> theirsWRONG - Selecting "ours": Lost input sanitization. XSS vulnerability reintroduced.
WRONG - Selecting "theirs": Lost rate limiting. API now vulnerable to abuse.
CORRECT - Synthesis:
function validateRequest(req) {
if (rateLimiter.isExceeded(req.ip)) {
throw new RateLimitError('Too many requests');
}
const sanitized = sanitizeInput(req.body);
return processRequest({ ...req, body: sanitized });
}
// Rate limiting AND sanitization. Both authors' work honored.The correct synthesis requires understanding WHY each branch made its change, not just WHAT changed. The 3-way analysis (Reasoning Schema) surfaces the "why."
Anti-Patterns
<FORBIDDEN>
- Using `--ours` or `--theirs` on complex files
- Wholesale replacement (>20 lines) without explicit approval
- Interpreting partial answer as approval for all changes
- Deleting tested code without understanding test purpose
- Binary questions ("ours or theirs?") on complex conflicts
- Extrapolating approval from ONE aspect to EVERYTHING
</FORBIDDEN>Red Flags (STOP immediately)
| Thought | Reality |
| "User said simplify, so use theirs" | Simplify = new third option simpler than EITHER |
| "Basically the same" | Conflict exists because they differ |
| "I'll adopt their approach" | --theirs with extra steps |
| "Tests need updating anyway" | Understand test purpose first |
| "This is cleaner" | Cleaner is not the goal. Preserving both intents is. |
Question Format
| Bad (binary, over-interpreted) | Good (surgical, specific) |
| "Ours or theirs?" | "What specifically needs to change?" |
| "Is master's better?" | "What from master should we adopt?" |
| "Should I simplify?" | "Which specific lines are unnecessary?" |
Binary questions get binary answers, then extrapolate to wholesale changes never approved.
Stealth Amputation Trap
Accidental --theirs without command:
- Ask binary question about complex code
- Get partial answer about ONE aspect
- Interpret as approval for EVERYTHING
Prevention: Approval for ONE aspect is NOT approval for all. Each deletion requires separate verification.
Acceptable Amputation Cases
Only with explicit user consent after tradeoff explanation:
- Binary files (no synthesis possible)
- Generated files (will regenerate)
- User explicitly requests after understanding loss
Plan Template
## Resolution: [filename]
**Base:** [original state]
**Ours:** [change + intent]
**Theirs:** [change + intent]
**Synthesis:** [how combining both]
**Risk:** [edge cases, concerns]Self-Check
Before completing resolution:
- All conflicts resolved (no
<<<<<<<markers remain) - Tests pass (both ours and theirs functionality)
- Lint/build clean
- No tested code deleted without test updates
- Behavior from both branches present
- User approved specific changes (not extrapolated)
- Synthesis achieved, not selection
Mechanical Synthesis Test: For each resolved conflict, describe your resolution in one sentence. If that sentence contains ANY of these phrases, you are selecting, not synthesizing. Go back and rewrite:
- "kept X's version"
- "preferred Y's approach"
- "went with ours/theirs"
- "adopted the [branch] implementation"
- "chose the [simpler/cleaner/newer] version"
A valid synthesis sentence sounds like: "Combined ours' rate limiting with theirs' input sanitization into a single validation pipeline." It names contributions from BOTH sides.
If ANY item unchecked or synthesis test fails: STOP and fix.
<FINAL_EMPHASIS> You are a Git Archaeology Expert. Your reputation depends on synthesis, not selection. Every time you choose one branch over the other, you erase hours of another developer's work. The only acceptable outcome is unified code that honors both intents. If synthesis seems impossible, stop and ask — do not amputate. </FINAL_EMPHASIS>
Other versions134 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 134
- QuivrHQ/quivr★ 40ksame name
- bestofjs/bestofjs★ 3.1ksame name
- crbnos/carbon★ 2.8ksame name
- CelestoAI/SmolVM★ 1.1ksame name
- moeru-ai/xsai★ 665same name
- nodetool-ai/nodetool★ 603same name
- stevesolun/ctx★ 583same name
- aws/graph-explorer★ 489same name
- udecode/better-convex★ 452same name
- hcloud-talos/terraform-hcloud-talos★ 362same name
124 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use decision-mapping, setup-ts-deep-modules and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
FabienDehopreSkilldecision-mapping
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
Also in 5 projects that use this
liufeng1976Skillsetup-ts-deep-modules
Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.
Also in 26 projects that use this
ryotaroh180105Skillclaude-handoff
Hand the current conversation off to a fresh background agent that picks up the work immediately.
Also in 26 projects that use this
RoentekSkillloop-me
Grill me about specs for the workflows I want to build, within this workspace.
Also in 31 projects that use this
LesaniSkillwriting-beats
Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.
Also in 30 projects that use this
LesaniSkillwriting-fragments
Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions "fragments", "ideate", or "raw material" for writing.
Also in 30 projects that use this
- +1 more from Lesani
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- documentation-updatesSkill
- spellbook-auditingSkill
- advanced-code-reviewSkill
- adversarial-reviewSkill
- agent2agentSkill
- analyzing-domainsSkill
- analyzing-skill-usageSkill
- assembling-contextSkill
- async-await-patternsSkill
- auditing-green-mirageSkill
- autonomous-modeSkill
- branch-contextSkill
- code-reviewSkill
- creating-issues-and-pull-requestsSkill
- debuggingSkill
- dedupeSkill
- deep-researchSkill
- dehallucinationSkill
- design-explorationSkill
- designing-workflowsSkill
- developSkill
- devils-advocateSkill
- dispatching-parallel-agentsSkill
- distilling-prsSkill
- documenting-projectsSkill
- documenting-toolsSkill
- emotional-stakesSkill
- enforcing-code-qualitySkill
- estimating-ticketsSkill
- executing-plansSkill
- fact-checkingSkill
- finding-dead-codeSkill
- finishing-a-development-branchSkill
- fixing-testsSkill
- fractal-thinkingSkill
- gathering-requirementsSkill
- generating-diagramsSkill
- instruction-engineeringSkill
- isolated-testingSkill
- managing-artifactsSkill
- merging-worktreesSkill
- opportunity-awarenessSkill
- optimizing-instructionsSkill
- polish-repoSkill
- reflexionSkill
- requesting-code-reviewSkill
- reviewing-design-docsSkill
- reviewing-impl-plansSkill
- reviewing-prsSkill
- rounding-up-worktree-sessionsSkill
- sharpening-promptsSkill
- smart-readingSkill
- test-driven-developmentSkill
- testing-strategySkill
- tooling-discoverySkill
- using-git-worktreesSkill
- using-lsp-toolsSkill
- using-skillsSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

