解决合并冲突

已归档。 该技能在 v1.3.0 中已从插件中移除，不再维护。没有替代品：代理无需专用技能即可处理合并或变基冲突。此页面保留以供参考。

它的作用¶

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

它拒绝把冲突当作文本问题。在处理任何差异块之前，它会将每一方追溯至其 主要来源（提交信息、PR、原始 issue），因此它是在两种意图之间做选择，而不是在两段文本之间做选择；只要双方兼容，它就会同时保留两者。在它们不兼容的地方，它会选择符合合并声明目标的一方，并说明取舍。它不会发明新的行为来掩盖冲突，也从不使用 --abort。它总是将合并带到一个已完成的提交。

何时使用它¶

输入 /resolving-merge-conflicts，或者当某个任务适合时，代理 会自动使用它。

当 git 已经停在它无法自行解决的冲突上时，就应使用它。它的范围仅限于你眼前的冲突，而不涉及冲突两侧的任何内容：

优先使用主要来源，而非 ours 和 theirs¶

本技能的存在是为了防止按标记解析：--ours、--theirs，或手动删除看起来不那么重要的那一块，以便让标记消失、构建通过。那样做可能在语法上完美无缺，却仍会静默丢弃某人刻意做出的修改。

你无法保留一个你从未读过的意图。因此，工作从历史（提交、PR、工单）开始，之后才转向 diff。检查步骤的存在也出于同一原因。本技能会找到仓库自身的自动化检查，并在提交前运行它们，因为在 git 中，合并最容易产生这样一种代码：它同时满足两个分支，却通不过任何一方的测试。

常见问题¶

Claude Code 自己已经能很好地解决冲突，为什么这还需要一个技能？

附加值在于“找到主要来源”和“运行反馈循环”这两个步骤，否则你每次都必须手动提示。未经提示的代理通常仅凭 diff 就会得出一个看似合理的解析，然后就此打住。本技能的价值在于它不允许代理跳过的两个步骤：阅读每一方存在的原因，以及随后运行检查。相比优秀的模型，这只是很小的增益——而这正是有意为之。至少有一位读者已经预测，随着模型改进，这整个技能会变成一个空操作。

我是否应该让并行代理避开相同文件，以便从一开始就避免冲突？

大多数情况下不需要。在并行任务之间划分文件区域，成本高于收益，因为代理处理合并冲突的能力已经足够好，取舍并不像看起来那么严苛。唯一值得保留的纪律是：先做大型重构。一个大型重命名如果是在十个分支从它分出之后才落地，这种情况依然代价高昂。

来自并行 worktree 用户报告的一个提醒：当并行的会话各自在自己的树中构建一个工单时，最好由写出该变更的那个会话来执行合并回主分支，因为它已经知道意图。如果由一个代理在最后解析所有人的冲突，它会丢失本技能第 2 步必须重建的上下文。

为什么从不使用 --abort？

中止会丢弃已完成的解析工作，并在你下次尝试时把你送回同一个未改变的冲突。本技能是为“合并无论如何都会发生”的情况而写的。如果你已决定它不应该发生，那应该是在调用之前做出的决定，而不是循环内部的一个分支。

生效的迹象¶

• 代理在解析过程中引用提交信息、PR 或 issue，而不仅仅是 diff 差异块。
• 每个差异块最终都包含两侧的行为，或附有一条明确说明，指出丢弃了什么以及为什么。
• 结果中没有出现原本不在任何分支上的内容。
• 代理在提交之前就找到类型检查、测试和格式化并让它们全部通过，而不是在你发现问题之后。
• 你最终会得到一个干净的工作树，操作已完成，包括多提交变基中的每一个剩余提交。

适用位置¶

这是一个随时可用的独立技能，不依赖任何其他技能：它从 git 卡住时开始，到工作树干净且已提交时结束。它唯一真正的邻居是 diagnosing-bugs，后者在合并已干净解决但合并后的代码行为异常时接管：这是一个诊断问题，而不是冲突问题。它位于从想法到交付的主流程之外，因此 ask-matt 是了解其前后运行内容的导航图。