/resolving-merge-conflicts 技能

它的作用

resolving-merge-conflicts 逐块处理进行中的 git 合并或变基，然后运行项目自己的检查，并以一次提交完成操作。

它拒绝把冲突当作文本问题。在触碰一个块之前，它把每一方追溯回它的 第一手资料 ——提交消息、PR、原始 issue——所以它是在两个意图之间选择，而不是在两块文本之间，并且在它们兼容的地方保留双方。在确实不兼容的地方，它选择匹配合并声明目标的一边并点名权衡。它不会发明新行为来掩盖冲突，而且 --abort 不是它拥有的选项：合并总是被进行到一个完成的提交。

何时使用

输入 /resolving-merge-conflicts，或这个 agent 任务合适时会自动调用它。

当 git 已经停在它无法自行解决的冲突上时使用它。它限定在你面前的冲突，不涉及它任何一侧的东西：

第一手来源优先于 ours and theirs

它存在要消灭的失败模式是按标志位解析： --ours, --theirs，或手动删除看起来不那么重要的块，让标记消失、构建编译通过。这种解决方式可能在语法上完美，却仍然静默丢掉某人有意做出的改动。

你无法保留你从未读过的意图。所以工作从历史开始——提交、PR、 tickets ——然后才移动到 diff。循环中还有一步出于同样的原因存在：技能找到仓库自己的 自动化检查 并在提交前运行它们，因为合并是 git 里最容易产出「同时满足两个分支、却通不过任何一方测试」代码的地方。

常见问题

Claude Code 自己解决冲突已经相当好了。为什么还需要一个技能？

增值在于「找第一手来源」和「运行反馈循环」两步，否则每次都得手动提示。没有提示的智能体通常只从 diff 就能产出貌似合理的解决方案并就此打住。技能的价值在于它不让智能体跳过的两步——阅读每一方存在的原因，以及事后运行检查。这比一个好的 model，而且这是有意的：至少一位读者预测过，随着模型改进，这会变成一个完全无操作的技能。

我应该从一开始就让并行智能体避开同一批文件以避免冲突吗？

大多不需要。在并行任务之间给文件分区，代价大于收益，因为智能体处理合并冲突已经足够好，权衡并不像看起来那么残酷。值得保留的一条纪律是先做大型重构。十个别分支都 fork 出去之后才落地的重大重命名，永远是昂贵的那个。

来自一份并行 worktree 用户报告的一个提醒：当兄弟 sessions 各自在自己的树里构建一个任务，合并回来最好由写下改动的那个会话完成，因为它已经知道意图。最后把所有人的冲突批量丢给一个智能体，恰好丢掉了 context 本技能的第 2 步不得不去重建。

为什么从不 --abort?

中止会丢弃解决工作，下一次尝试时让你回到同一个未改变的冲突。该技能是为「合并势在必行」的情况而写的。如果你已决定它不该发生，那是调用之前就该做的决定，而不是循环内的一个分支。

做到以下就算成功

• 智能体在解决过程中向你引用提交消息、PR 或 issue，而不只是 diff 块。
• 每个块都以双方的行为收场，或带有明确说明丢失了什么以及为什么。
• 结果中不会出现任何两个分支都没有的东西。
• 类型检查、测试和格式化被定位并全绿运行 before 提交时，而不是在你发现异常之后。
• 你以干净的工作树和完成的操作收尾——包括多提交变基中的每一个剩余提交。

在流程中的位置

一个不依赖任何其他技能的随时可调用独立技能：它在 git 卡住时启动，在工作树干净并提交后结束。它唯一真正的邻居是 diagnosing-bugs，它在「合并干净地解决了但合并后的代码行为异常」这个点接手——这是诊断问题，不是冲突问题。它完全脱离主流程，所以 ask-matt 是在它之前和之后运行内容的地图。