gitconflicts

# Git Conflicts ## Status !`bun ${CLAUDE_PLUGIN_ROOT}/skills/conflicts/scripts/status.ts` ## Context !`bun ${CLAUDE_PLUGIN_ROOT}/skills/conflicts/scripts/context.ts` ## Upstream !`bun ${CLAUDE_PLUGIN_ROOT}/skills/conflicts/scripts/upstream.ts` ## Three-Way Access Git stores three versions in staging slots during a conflict: | Slot | Version | Command | |------|---------|---------| | `:1:path` | Base (common ancestor) | `git show :1:path` | | `:2:path` | Ours (HEAD) | `git show :2:path` | | `:3:path` | Theirs (incoming) | `git show :3:path` | ## Resolving For each conflicted file: - Read the three slots above to understand base, ours, and theirs. - Edit the file to produce the correct merged result, then `git add` it. - For generated files (lockfiles, build artifacts), delete and regenerate rather than merge by hand. Follow the project's `CLAUDE.md` for lockfile-specific guidance. - Never silently drop either side. When in doubt, keep both and ask. - If a conflict is in a file you don't understand, ask rather than guess. ## Committing and Pushing This step runs only when you are asked to take the operation to completion: the `--push` argument (its alias `push`), or a request like "fix conflicts and push". By default, on auto-activation or when asked only to resolve, stop after `git add` and do not commit, continue, or push. When driving to completion: 1. **Initiate the merge if needed.** If no rebase, merge, or cherry-pick is in progress but upstream has diverg...