Resolve merge conflicts

Use during authorized integration without requiring a separate invocation. Loading this skill grants no integration authority: inspect the original task and project policy for the operation, branches and permitted completion. A request only to inspect conflicts stays read-only. Do not start a new merge/rebase just because conflicts are mentioned.

1. Inspect the operation and protect existing work

Read project instructions and the integration goal. Inspect git status, branch/HEAD, recent history, staged and unstaged diffs, untracked files and git ls-files -u. Identify the merge heads or current rebase commit and target; detached HEAD can be normal during rebase. Use git rev-parse --git-path for operation metadata, including in linked worktrees. If no merge/rebase is active, report that state rather than guessing a different operation.

Record the starting HEAD, operation/target, conflict paths, intended resolution scope, and protected work's bytes, modes, symlink targets and index entries. Distinguish cleanly integrated staged changes belonging to this operation from unrelated staged work; use the caller's pre-operation evidence when available. Unknown ownership blocks conflicting writes and eventual completion, not safe inspection elsewhere. Preserve untracked files and unrelated history too. No automatic stash, reset, checkout of whole sides, clean or index manipulation to clear an obstacle.

Complete when: authority, operation and owned paths are known, and unrelated/uncertain work is identified and protected.

2. Resolve compatible intent

Read Git mechanics before resolving; it covers stage meanings, non-text conflicts and safe staging/continuation. For each conflict inspect available base and side versions, surrounding code/callers/tests, commit messages and relevant task/PR decisions. During rebase, derive side identity from the current operation rather than interpreting “ours” as the user's original branch.

Resolve each compatible conflict so both intended effects survive; include necessary related edits only within approved scope. Inspect whole-file behavior, not just marker removal. Treat modify/delete, rename, binary, executable-bit, symlink and submodule conflicts according to their actual data and intended outcome. Missing content, incompatible product rules or uncertain meaning requires a decision, not a guessed winner or invented behavior.

Preserve completed resolutions and pause the affected integration with the conflicting intentions, paths/commits, exact decision needed and recommended next step. Do not stage a partial file as fully resolved. Stage only fully inspected resolution paths with explicit path arguments; verify the staged result and protected index/worktree against the baseline.