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.

Task: Resolve merge conflicts and explain the result · Other tasks

Fill in the details

What each side was meant to do (required)

One or two sentences per side. The goal of each change matters more than the exact lines.

Branch you are merging or rebasing onto

Optional. Leave empty if the merge or rebase is already in progress and Claude can see it.

Command to check the result

Optional. Leave empty and Claude will find how the project builds and runs its tests.

Copy your prompt

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

Your prompt (you can edit it)

Resolve the merge conflicts in this branch, and explain what you kept from each side.

What each side was meant to do:
[fill in: What each side was meant to do]

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. 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.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

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.

Code review prompt: 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: 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: 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.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code best practices: Provide specific context in your prompts (Anthropic documentation)
Claude Code best practices: Give Claude a way to verify its work (Anthropic documentation)