结合提交、PR 和需求背景处理进行中的 merge 或 rebase 冲突，再运行检查完成操作。
安装与准备
在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill resolving-merge-conflicts --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /resolving-merge-conflicts 换成 $resolving-merge-conflicts。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:resolving-merge-conflicts，不要再重复安装文件版本。
适用于已经进入冲突状态的 Git 仓库。先了解当前分支、正在合并的目标以及需要保留的修改。这个 Skill 的默认流程会暂存并提交、继续 rebase，开始前要确认工作范围。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/resolving-merge-conflicts
当前是合并 main 时的冲突。我的分支添加导出字段，main 修改了权限检查。请保留权限校验和新字段的意图，查看两边提交背景后解决，并运行项目检查。
怎样推进任务
理解冲突发生的位置
先检查 Git 状态和冲突文件，辨认这是 merge 还是 rebase。把提交信息、关联 PR 和需求作为背景。单纯选择 ours 或 theirs 很容易保留导出字段却丢失权限检查，或反过来。
逐块保留业务意图
让 Agent 解释每个冲突块两边分别想改变什么，再组合兼容的行为。碰到无法同时保留的规则，回到这次合并的目标，明确采用哪一种语义；不要借解决冲突顺便增加第三种未讨论的功能。
通过检查后完成 Git 操作
运行项目已有的类型检查、测试和格式检查。对于导出例子，要覆盖有权限和无权限访问，以及新增列的数据。rebase 可能在后续提交再次停下，需要逐次处理到流程结束。
完成后检查什么
Git 状态中不应再有未合并文件，也不应仍提示 rebase 进行中。查看最终 diff 和相关测试结果，确认两边需求都保留，而不只是冲突标记消失。
常见问题
能用来决定是否放弃这次合并吗？ 它的默认目标是完成冲突解决；是否中止或重做属于另一个决策。
所有检查通过就肯定没问题？ 自动化检查只覆盖已有断言，仍要对照两边需求阅读修改。
会发到远程吗？ 本身描述的是完成本地合并或 rebase；推送应单独明确。
用一次配置冲突检查两边意图
假设你的分支新增邮件通知开关，主分支同时把默认通知改为关闭。可以输入：“当前 rebase 停在通知配置冲突。请先读双方提交与关联需求，保留新的用户开关，同时遵守主分支的关闭默认值；不要发明第三套通知规则。完成每个冲突后运行现有通知测试，继续到 rebase 结束。”先从 Git 状态确认实际操作类型和剩余提交。
验收不能只看冲突标记消失：新用户默认关闭、旧用户已有选择被保留、切换开关后发送行为符合规则，这三种行为都要在合成后的代码里说得通。若某一处根本无法同时保留两边，要求说明舍弃了哪一项及原因。还有 rebase 进行中时，不要把当前文件的绿色测试误报为全部完成。
rebase 卡在编辑器时
确认冲突标记已清除、测试已跑且将要保留的提交说明无误之后，再继续 rebase。有使用者在这个环节遇到 git rebase --continue 启动交互编辑器，Agent 因等待输入而长时间停住。若你看到进程没有返回，先判断是不是编辑器在等待；需要非交互继续时，确认提交信息后为本次命令设置合适的 GIT_EDITOR，再核对 git status、提交历史与测试结果。不要把“命令仍在运行”当作冲突已解决。