resolve-conflict 用于在 Git rebase 或 merge 过程中解决冲突。它的核心思路是先理解冲突为何发生、两侧分支各自想做什么，再产出既正确又能尽量保留双方意图的解决方案。
主要能力与工作流程：
-
评估当前状态：通过 git status 判断处于 rebase（.git/rebase-merge/ 或 .git/rebase-apply/ 存在）还是 merge（.git/MERGE_HEAD 存在），并列出所有“both modified”或“Unmerged paths”冲突文件；若不存在冲突操作则告知用户并停止。
-
理解各分支上下文：对 rebase，查看正在 rebase 到的目标分支（onto）、当前被重放的提交（stopped-sha / REBASE_HEAD）及其提交说明，以及目标分支上与之冲突的改动；对 merge，分别查看当前分支（MERGE_HEAD..HEAD）与被合并分支（HEAD..MERGE_HEAD）对冲突文件的改动。
-
分析每个冲突文件：读取冲突标记（<<<<<<< 与 >>>>>>> 之间区域），用 git show :2:<file>（ours）、:3:<file>（theirs）、:1:<file>（base 共同祖先）做三方对比，弄清 base 原貌、ours 相对 base 改了什么、theirs 相对 base 改了什么。随后将每处冲突归类为非重叠（合并双方改动）、互补（择更优或合并，不明确时询问）、竞争（双方对同一逻辑做了有意的矛盾改动，需询问用户）、单边（采纳有意义的一侧，忽略格式或重排等附带改动）。
-
解决冲突：编辑文件得到正确结果，尽量保留双方意图，保持语法正确（无缺失导入、括号等），确保不残留冲突标记，并与文件及代码库其余部分保持一致；随后用 git add <file> 暂存。
-
何时询问用户：当双方对同一逻辑做了有意的竞争性改动且不知如何合并、涉及无法仅凭代码上下文判断的业务逻辑决策、提交信息与代码上下文不足以判断意图、或采纳一方会破坏另一方功能时，应停止并清楚说明双方各自做了什么、为何冲突、有哪些选项。
-
验证与汇报：用 git diff --check --cached 确认无冲突标记，用 git status 确认无未合并路径；必须运行项目的 lint 和类型检查，若失败则修复并重跑直至通过，项目若未配置 lint 或类型检查需在总结中明确说明。最后按“冲突解决总结”格式汇报上下文（操作类型、base 分支、来源分支或提交）、每个文件双方改动及解决方式，以及后续可选命令（查看暂存改动、继续 rebase、继续 merge、中止操作）。
使用方式与重要提醒：该技能默认只暂存文件，不提交，也不运行 git rebase --continue / git merge --continue，除非用户明确要求；它只告诉用户下一步该运行什么命令。需注意 ours/theirs 语义在 merge 与 rebase 之间相反：rebase 时 ours 是目标分支、theirs 是被重放的提交；merge 时 ours 是当前分支、theirs 是被合并分支，解决前应通过提交哈希确认。若 :1:<file> 读取失败，可能该文件在两个分支上都是新增，此时应把两版都视为全新内容并逻辑合并。
适用场景：需要在 rebase 或 merge 中安全、可追溯地解决 Git 冲突，尤其是希望保留双方改动意图、避免误判的多人协作项目。限制：不自动提交或继续操作；不编造业务逻辑判断，信息不足时需用户介入；未提供 lint 或类型检查配置时无法执行相应检查。