Skill Vault · Build and check
Resolve a Git conflict with context
Trace what both changes intended before resolving a merge or rebase.
A repository in a merge or rebase conflict, with history and checks available.
Skill name /resolving-merge-conflicts
Your next step
Try it for yourself
You’ll need: A repository in a merge or rebase conflict, with history and checks available.
Paste into your coding agent with the relevant project open.
This is a one-off starter for the approach. Installing the full Skill adds its complete instructions.
Resolve the current merge or rebase. Trace each conflict to the commits, issues, and tests that explain both intents. Preserve both where compatible, finish the operation, and run the repository checks. Never abort.
What happens nextCompatible intentions survive the resolution and repository checks run.
Use it again
Add the full Skill.
The starter lets you try the approach. Installation adds the complete instructions to your AI coding tool.
Copy the setup instructionsFor Codex or Claude Code on your computer
Your next step
Ask your agent to help you install it
You’ll need: Node.js with npx, Git, and the agent you choose. A project folder where you want the Skill available.
Paste this into Codex or Claude Code with your project open. Your agent will help you review and install the package.
Review files and permissions before accepting an install. Adding a Skill does not run it.
Help me install /resolving-merge-conflicts from MattEspo23/skills v0.1.2 in this project.
Review the package instructions and supporting files first. Include these Skills: resolving-merge-conflicts.
Use the command for the agent I am using:
Add to Codex:
npx skills@latest add 'MattEspo23/skills#v0.1.2' --skill resolving-merge-conflicts --agent codex --copy
Add to Claude Code:
npx skills@latest add 'MattEspo23/skills#v0.1.2' --skill resolving-merge-conflicts --agent claude-code --copy
Show me where the files will go before making changes. Preserve existing Skills and customizations. Stop if the release, supporting Skills, or target agent cannot be verified. Do not run the Skill or change external services during setup.
After installation, explain how I can use /resolving-merge-conflicts and what access it needs.
What happens nextYour agent should review and add /resolving-merge-conflicts, then explain how to use /resolving-merge-conflicts. Stop if a dependency or version cannot be verified.
No additional supporting Skill is required by this package. Source version: v0.1.2.
Prefer a terminal command?
Add to Codex
npx skills@latest add 'MattEspo23/skills#v0.1.2' --skill resolving-merge-conflicts --agent codex --copy
Add to Claude Code
npx skills@latest add 'MattEspo23/skills#v0.1.2' --skill resolving-merge-conflicts --agent claude-code --copy
Installing copies the instructions into your chosen agent. It does not run the Skill or configure project tools.
Keep the package’s supporting files, LICENSE and NOTICE together with the Skill instructions.
Full notes & source materialThe complete original text, examples and reference details.
These are the complete original notes. Planned videos and services mentioned here may not be available yet; the actions above reflect what you can use on this site now.
Resolve an active merge or rebase conflict hunk by hunk using each side’s original intent.
Watch
Skill Vault video planned · Video planned
Install
Public release v0.1.2 — install the latest source or pin the tested release.
Install latest
npx skills@latest add MattEspo23/skills --skill resolving-merge-conflicts
Reproducible install
npx skills@latest add 'MattEspo23/skills#v0.1.2' --skill resolving-merge-conflicts
Clean installs are verified for Codex and Claude Code. The installer copies editable files into the selected agent; review every Skill before giving it tool access.
This is the public, editable adapted baseline. Its deeper Espo-specific revision and Skill Vault video are planned; the released source can be installed now.
What it does
resolving-merge-conflicts works through an in-progress git merge or rebase, hunk by hunk, then runs the project's own checks and finishes the operation with a commit.
It refuses to treat a conflict as a text problem. Before touching a hunk it traces each side back to its primary source — the commit message, the PR, the original issue — so it is choosing between two intents rather than between two blocks of text, and it preserves both wherever they are compatible. Where they genuinely are not, it picks the side matching the merge's stated goal and names the trade-off. It invents no new behaviour to paper over a clash, and --abort is not an option it has: the merge is always carried to a finished commit.
When to reach for it
Type /resolving-merge-conflicts, or the agent reaches for it automatically when a task fits.
Reach for it when git has already stopped on conflicts it could not resolve itself. It is scoped to the conflict in front of you, not to anything either side of it:
| Your situation | Skill |
|---|---|
| Mid-merge or mid-rebase, conflict markers in the tree | This one |
| Merge finished, something now misbehaves for reasons you can't see | diagnosing-bugs |
| Planning how to slice work so branches collide less | Neither — see the parallel-work question below |
Primary sources over ours and theirs
The failure mode this exists to kill is resolving by flag: --ours, --theirs, or hand-deleting whichever block looks less important, so the markers go away and the build compiles. That resolution can be syntactically perfect and still silently drop a change somebody made on purpose.
You cannot preserve an intent you have not read. So the work starts in the history — commits, PRs, tickets — and only then moves to the diff. Another step in the loop exists for the same reason: the skill finds the repo's own automated checks and runs them before committing, because a merge is the easiest place in git to produce code that satisfies both branches and passes neither's tests.
Common questions
Claude Code already resolves conflicts pretty well on its own. Why does this need a skill?
The added value is the "find the primary sources" and "run feedback loops" steps, which otherwise have to be prompted by hand every time. An unprompted agent will usually produce a plausible resolution from the diff alone and stop there. The skill's value is the two steps it will not let the agent skip — reading why each side exists, and running the checks afterwards. That is a thin margin over a good model, and it is meant to be: at least one reader has predicted this is a whole skill that becomes a no-op as models improve.
Should I keep parallel agents off the same files to avoid conflicts in the first place?
Mostly no. Zoning files off between parallel tasks costs more than it saves, because agents are good enough at merge conflicts that the tradeoff is not as harsh as it looks. The one piece of discipline worth keeping is to do large refactors first. A large rename landing after ten branches have forked off it is the case that stays expensive.
One caveat from a user report on parallel worktrees: when sibling sessions each build a ticket in their own tree, the merge back is best done by the session that wrote the change, because it is the one that already knows the intent. Batching everybody's conflicts onto one agent at the end throws away exactly the context step 2 of this skill has to go and reconstruct.
Why never --abort?
Aborting throws away the resolution work and returns you to the same conflict, unchanged, the next time you try. The skill is written for the case where the merge is going to happen. If you have decided it should not happen, that is a decision to make before invoking, not a branch inside the loop.
It's working if
- The agent quotes commit messages, PRs or issues at you while resolving, not just diff hunks.
- Every hunk ends up with both sides' behaviour, or with an explicit note naming what was dropped and why.
- Nothing appears in the result that was on neither branch.
- Typecheck, tests and format were located and run green before the commit, not after you noticed something broken.
- You end on a clean tree with the operation completed — including every remaining commit in a multi-commit rebase.
Where it fits
A reach-for-it-anytime standalone with no dependencies on any other skill: it starts when git stalls and ends when the tree is clean and committed. Its only real neighbour is diagnosing-bugs, which takes over at the point where a merge resolved cleanly but the merged code misbehaves — a diagnosis problem, not a conflict one. It sits off the main idea-to-ship flow entirely, so ask-espo is the map for what runs before and after it.
Try it once
Use the core behavior in one conversation before installation. The repeatable Skill package is the primary path when you want the behavior available across future work.
Resolve the current merge or rebase. Trace each conflict to the commits, issues, and tests that explain both intents. Preserve both where compatible, finish the operation, and run the repository checks. Never abort.
Source & license
Released in EspoAI Skills v0.1.2; adapted from mattpocock/skills v1.2.3. The released package is skills/engineering/resolving-merge-conflicts/SKILL.md.
The public package is MIT-licensed and pinned here to the exact release commit. View the released EspoAI source
The adapted baseline preserves the upstream copyright, MIT permission notice, and pinned provenance. View the original pinned source
Skill package files
The full Skill text as copied from content/skill-vault/skills/resolving-merge-conflicts/. Supporting agent configuration files stay in that folder.
SKILL.md
---
name: resolving-merge-conflicts
description: "Use when you need to resolve an in-progress git merge/rebase conflict."
---
1. **See the current state** of the merge/rebase. Check git history, and the conflicting files.
2. **Find the primary sources** for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. Always resolve; never `--abort`.
4. Discover the project's **automated checks** and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
5. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.
Keep going