What this prompt does
This prompt frames the model as a senior engineer who resolves gnarly merge conflicts without breaking behaviour, instructing it to specify the resolution tightly enough to apply and not rewrite unrelated lines. Three placeholders focus it: [branch_a] and [branch_b] (the two sides being merged) and [file] (the conflicted file to resolve).
The structure works because the dangerous conflicts are semantic, not textual — code that merges cleanly but behaves wrong, like a renamed function or a flipped default. By demanding a per-hunk breakdown explaining which side to keep and why, a unified resolution for [file], explicit flags for semantic conflicts, the specific tests mapped to the changed behaviour, and a safe-abort note, the prompt makes you reason hunk by hunk instead of blindly accepting one side. The mapped tests catch the conflicts that compile fine but page you at 2am. Naming [branch_a] and [branch_b] gives the model the context to explain each side's intent, so it can argue why one wins rather than picking arbitrarily.
When to use it
- Two branches touched the same file and
git mergeleft conflict markers you need to reason through. - You are merging shared backend code where a wrong default could silently change behaviour.
- You want a per-hunk explanation of which side to keep rather than guessing.
- You need semantic conflicts flagged — renames or changed defaults Git will not catch.
- You want the specific tests to run mapped to what actually changed.
- You want a safe-abort path (
git merge --abort) if the resolution looks wrong.
Example output
Expect three sections in order: the hunk-by-hunk decisions (which side of [branch_a] vs [branch_b] to keep for each conflict in [file], and why), then the full resolved file with brief comments at any non-obvious merge decision and explicit flags on semantic conflicts, then the test commands to run mapped to the changed behaviour. A safe-abort note explains how to bail out with git merge --abort if the result looks off.
Pro tips
- Give the model the real
[file]content with conflict markers; it can only reason hunk by hunk if it sees both sides. - Run the mapped tests immediately after resolving — the conflicts that compile fine are exactly the ones that break behaviour quietly.
- Pay attention to the semantic-conflict flags; a function renamed on
[branch_a]but called the old way on[branch_b]will merge clean and still be wrong. - If the resolution feels uncertain, take the
git merge --abortpath rather than committing a guess. - Tell it not to touch unrelated lines so the diff stays reviewable and you can trace every change to a real merge decision.
- Ask for a comment at any non-obvious merge decision so the next reader understands why one side of
[file]survived. - When a hunk combines logic from both branches, double-check the merged version against each side's intent rather than assuming concatenation is correct.
