# Resolve merge conflicts and explain the result

Tell Claude Code what each branch was meant to do; it resolves the conflicts, runs your checks and explains what it kept from each side.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Resolve the merge conflicts in this branch{{#other}} against {{other}}{{/other}}, and explain what you kept from each side.

What each side was meant to do:
{{intent}}

The goal is code that does what both sides intended, not just files without conflict markers. For each conflicted file, read both versions and the commits behind them before you choose.

Rules:
- Do not commit, push, or continue or abort the merge or rebase. Leave the resolved files for me to review.
- Do not drop a change from either side without saying so.
- If a conflict needs a decision you cannot make from the code and my notes, leave it unresolved and ask me instead of guessing.
- When the conflicts are resolved, run the build and the tests{{#check}} with: {{check}}{{/check}}. Fix anything the merge broke, and keep going until they pass.

Report:
1. For each conflicted file: what you kept from each side, what you combined, and why.
2. Any change you left out, and the reason.
3. The final build and test output.
4. Conflicts you left open, with the question I need to answer for each.
```

## Fields

- `{{intent}}` (required): What each side was meant to do. One or two sentences per side. The goal of each change matters more than the exact lines.
- `{{other}}`: Branch you are merging or rebasing onto. Optional. Leave empty if the merge or rebase is already in progress and Claude can see it.
- `{{check}}`: Command to check the result. Optional. Leave empty and Claude will find how the project builds and runs its tests.

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- A merge or rebase stopped with conflicts in several files, and you want them resolved with a written reason for each choice instead of a silent pick of one side.
- Both branches made real changes to the same code, such as a rename on one side and new behavior on the other, so neither version is correct on its own.
- You want the result checked by the build and the tests before you look at it, so you review a working merge rather than a guess.

## When not to use it

- You already know one side should win for every file, for example when you are throwing away an old experiment. A plain git command does that faster.
- You cannot say what either branch was meant to do. Find out first, from the pull requests or their authors, because the resolution depends on intent.
- The conflicts are in generated files such as lock files or build output. Regenerate them with the project's own tool instead of merging them by hand.

## Why this structure

- The required field asks what each side was meant to do. With that, Claude can aim for a state where both intents hold, rather than choosing between conflict markers line by line.
- Reading both versions and the commits behind them is an explicit step, because a conflict hunk on its own often hides a related change elsewhere in the file.
- The rules keep the merge reviewable: no commit, no push and no continuing the merge or rebase, so the resolved files wait for you in the working tree.
- Running the build and the tests after resolving gives Claude a pass or fail signal. A merge that compiles can still break behavior, and the tests show that before you do.
- The report goes file by file and asks what was left out. That is the part to read closely, because a dropped change is the hardest merge mistake to notice later.
- Unresolved conflicts come back as questions, so Claude stops at decisions only you can make instead of inventing an answer.

## Example input (fictional)

What each side was meant to do:

```
My branch adds prices in more than one currency to the checkout. Main renamed the price helpers and moved them from utils/price.js to lib/money.js.
```

Branch you are merging or rebasing onto:

```
main
```

Command to check the result:

```
npm test && npm run build
```

## Follow-ups to send Claude

- Show me the combined diff for the price helpers only, and point out every line that came from neither side.
- I agree with your answers. For the open conflict in checkout.js, keep the new currency handling and use the renamed helper from main.
- The merge looks right. Write a short merge commit message that lists what was combined, but do not commit yet.

## Common mistakes

- Leaving out what each branch was for. Without it, Claude can only judge the code, and both versions may look reasonable on their own.
- Letting the merge be committed before you have read the report. Review the file-by-file explanation and the test output first, then commit yourself.
- Resolving a long-running branch in one go. If the branches have drifted far apart, merge the default branch in more often, or resolve and check one area at a time.

## Related templates

- [Code review prompt](https://awesomeclaudeprompts.com/prompts/code-review/): Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
- [Plan a code change before editing](https://awesomeclaudeprompts.com/prompts/plan-code-change/): Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.
- [Commit changes with a generated message](https://awesomeclaudeprompts.com/prompts/commit-with-message/): Have Claude Code read the diff, check for files that should not go in, and commit with a message that says what changed and why. It does not push.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Provide specific context in your prompts](https://code.claude.com/docs/en/best-practices#provide-specific-context-in-your-prompts) (Anthropic documentation)
- [Claude Code best practices: Give Claude a way to verify its work](https://code.claude.com/docs/en/best-practices#give-claude-a-way-to-verify-its-work) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.