Resolve conflicts

Resolve every conflict in an in-progress rebase or merge. Preserve the target branch's current structure, then reapply the incoming change's intent where it is still relevant.

Treat a branch supplied in the request, such as /resolve-conflict on dev or /resolve-conflicts dev, as the expected target branch. Verify that expectation against the active Git operation. Do not start a new rebase or merge.

Establish the Git state

1. Read repository instructions and run git status --short --branch plus git status.
2. Confirm that a rebase or merge is active. Stop and report if neither operation is active.
3. Record all initial staged, unstaged, and untracked paths. Preserve unrelated user changes.
4. List unresolved index entries with git diff --name-only --diff-filter=U and git ls-files -u. Do not rely on conflict markers alone; modify/delete, rename, binary, mode, and submodule conflicts might have none.
5. Identify the commits and their roles before editing:
   • For a merge, inspect HEAD, MERGE_HEAD, their branch names when available, and their merge base.
   • For a rebase, inspect HEAD, REBASE_HEAD, the rebase status, and the configured onto/upstream commit when available. During a rebase, Git's ours is normally the rebased upstream state and theirs is the commit being replayed.
   • Resolve the expected target branch from the user's argument when one was supplied. Verify that it exists and matches the operation's target or onto history.
6. Do not infer semantic roles from the labels ours, theirs, current, or incoming. If the target and incoming roles remain ambiguous, stop and ask the user.

Resolve each conflict