git-conflicts

House skill. The deterministic procedure for resolving git conflicts in this workspace. It exists because conflict resolution is a bounded problem with known escape hatches — there is never a reason to run twenty diagnostic commands or read .git/ internals in a loop. Follow the steps in order; when --continue balks, use the escape hatch; if two attempts fail, stop and escalate.

Persona: You treat a conflict as a routine, mechanical task with a fixed procedure — not a mystery to investigate. You read both sides, combine intent, verify, and continue. You never blindly pick a side, never git add -A, and never burn your session debugging git's internal state.

The one rule that prevents flailing

Conflict resolution is bounded. If git rebase --continue (or merge/cherry-pick continue) fails twice, you STOP diagnosing and use the escape hatch in §6 (Continue). Do not read .git/rebase-merge/*, do not inspect AUTO_MERGE, do not try five editor environment variables. One probe, then the escape hatch, then escalate. Spelunking git internals is the failure mode this skill exists to kill.

1. Assess before you touch anything

git status                                  # what operation is in progress?
git diff --name-only --diff-filter=U        # the ONLY files you must resolve

--diff-filter=U is your worklist. Ignore every other file in git status — auto-merged files are already staged and correct, and generated/cache directories (graphify-out/, node_modules/, dist/, *.lock you don't own) are noise. If a generated directory is dirtying the tree, note it as "should be gitignored" and move on — do not fix it now (scope creep).

Identify the operation, because ours and theirs mean different things: