resolve-conflicts-by-intent
Use when Git reports conflicts during a merge, a rebase, or a cherry-pick. Also use it when the user says "fix the merge conflicts", "rebase onto main", or "the merge broke the build". Traces each sid
SKILL.mdskills/resolve-conflicts-by-intent/SKILL.md
GitHubResolve Conflicts by Intent
Use when
A merge, a rebase, or a cherry-pick stops with conflicted files. Each side of a conflict carries an intent. A correct resolution keeps each intent that still applies.
Gates
- For each conflicted file, can you name the commit and the intent behind each side?
- Does the resolution keep both intents when they fit together?
- When the intents do not fit together, did you ask the user instead of picking one?
- Did you check related names and code outside the conflict markers?
- Do the checks pass on the combined result, and did you separate failures that were already on a parent?
- Are all conflict markers gone, with no file left unmerged?
Process
- Read the operation in progress, the conflicted paths, and the commits on each side.
- For each side, read the commit message, the tests, and the design notes that explain it.
- Resolve each conflict in the current design. Keep the compatible parts of both sides.
- Search the rest of the code for names and assumptions that either side changed.
- Run the focused checks and the required merge check.
- Read the combined diff against both intents, then finish the operation that the user asked for.
Example
Situation: A rebase conflicts in a lock file. One side adds a package, and the other side updates a different package. Easy route: Take one whole side of the lock file, because a tool writes it. Hidden cost: One change is lost. The build passes on a machine that still has the old cache, and it fails for everyone else. Best route: Take the lock file from the base branch. Apply the package change from the other side again, and run the install so that the tool writes the lock file. Evidence: The new lock file has both packages. A clean install and the full check passed.
Guardrails
- Take a whole side of a file only when nobody wants that side any more.
- Keep schema changes, migrations, generated files, and tests consistent with each other.
- Treat rename and delete conflicts as behavior changes.
- Do not add a third design that neither side asked for.
- Keep unrelated edits of the user, and follow the approval rules of the repository for Git operations.
Completion
- Each conflicted file, with the intent that you kept from each side.
- The check that covers the combined behavior, with its result line.
- The operation that you finished, and the final commit hash.