How do I install the Resolving Merge Conflicts skill?

Run npx skillmds@latest add alexisbalayre/resolving-merge-conflicts in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Resolving Merge Conflicts safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Resolving Merge Conflicts?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Resolving Merge Conflicts free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Resolving Merge Conflicts?

AlexisBalayre (@alexisbalayre) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Resolving Merge Conflicts by alexisbalayre

Name: Resolving Merge Conflicts
Author: AlexisBalayre

File contents

See the current state of the merge/rebase. Check git status, the git history of both sides, and the conflicting files.
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 (gh pr view), check the original issues/tickets (PR bodies reference them with the TRACKER_ISSUE_PREFIX from .env).
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.
Regenerate, don't hand-merge. Conflict markers in generated files are never resolved by hand:
- Lockfiles (package-lock.json, yarn.lock, poetry.lock, uv.lock, Cargo.lock, go.sum, ...): merge the manifest first, take either side of the lockfile wholesale, then regenerate it with the project's package manager (INSTALL_CMD in .claude/project.env usually does it).
- Generated migrations and their metadata (journals, snapshots): drop this branch's generated migration, re-run the migration generator against the merged schema, then format the output with FORMAT_FIX_CMD.
- Any other generated artifact (paths matching GENERATED_PATHS_REGEX in .claude/project.env: codegen stubs, generated API references, schema diagrams): re-run its generator against the merged sources; never edit the output.
Run the automated checks and fix anything the merge broke. Formatting, lint, and typechecking run automatically via the Stop hook; run the tests yourself (TEST_CMD in .claude/project.env, scoped to the affected area when the runner allows). The pre-commit hook (scripts/pre-commit) runs the project's checks and tests; failures that already exist on the base branch are not the merge's fault, and --no-verify is acceptable only for those.
Finish the merge/rebase. Stage everything and commit. If rebasing, continue the rebase process (git rebase --continue) until all commits are rebased.

---name: resolving-merge-conflictsdescription: Resolve an in-progress git merge or rebase conflict. Use when a merge, rebase, or cherry-pick stops on conflicts.---1. **See the current state** of the merge/rebase. Check `git status`, the git history of both sides, 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 (`gh pr view`), check the original issues/tickets (PR bodies reference them with the `TRACKER_ISSUE_PREFIX` from `.env`).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. **Regenerate, don't hand-merge.** Conflict markers in generated files are never resolved by hand: - Lockfiles (`package-lock.json`, `yarn.lock`, `poetry.lock`, `uv.lock`, `Cargo.lock`, `go.sum`, ...): merge the manifest first, take either side of the lockfile wholesale, then regenerate it with the project's package manager (`INSTALL_CMD` in `.claude/project.env` usually does it). - Generated migrations and their metadata (journals, snapshots): drop this branch's generated migration, re-run the migration generator against the merged schema, then format the output with `FORMAT_FIX_CMD`. - Any other generated artifact (paths matching `GENERATED_PATHS_REGEX` in `.claude/project.env`: codegen stubs, generated API references, schema diagrams): re-run its generator against the merged sources; never edit the output.5. **Run the automated checks** and fix anything the merge broke. Formatting, lint, and typechecking run automatically via the Stop hook; run the tests yourself (`TEST_CMD` in `.claude/project.env`, scoped to the affected area when the runner allows). The pre-commit hook (`scripts/pre-commit`) runs the project's checks and tests; failures that already exist on the base branch are not the merge's fault, and `--no-verify` is acceptable only for those.6. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process (`git rebase --continue`) until all commits are rebased.

Frequently asked questions

Resolving Merge Conflicts