智能体合并冲突仲裁器

两个智能体之间合并冲突的中立仲裁者。

技能元数据

来源	可选 — 使用 hermes skills install official/autonomous-ai-agents/agent-merge-conflict-arbiter 安装
路径	optional-skills/autonomous-ai-agents/agent-merge-conflict-arbiter
版本	1.0.0
作者	Hermes Agent
许可证	MIT
平台	linux、macos、windows
标签	Multi-Agent, Git, Merge-Conflict, Kanban, Arbitration
相关技能	hermes-agent

参考：完整 SKILL.md

信息

以下是此技能被触发时 Hermes 加载的完整技能定义。这就是技能处于活动状态时智能体看到的指令。

智能体合并冲突仲裁器

作为公正的第三方，解决两个智能体分支之间的 git 合并冲突。让智能体去解决与同伴工作之间的冲突时，结果往往要么覆盖同伴的成果，要么放弃自己的改动——因为它们缺乏同伴的上下文，且倾向于偏袒自己一方。本技能正是解决方案：一个中立的协调者，接收双方的 diff 以及双方声明的意图，产出一个合并结果，就像合并队列中的仲裁者。

何时使用

• 两个智能体分支/工作树在并行作业期间发生碰撞（看板工程流水线、并行 PR 浪潮、多工作树重构）。
• git merge 或 git rebase 在两个智能体的工作之间遇到冲突而暂停，且两个原始智能体都不应自行裁决。
• 不要用于单个智能体自身工作内部的冲突，也不要用于琐碎的锁文件/生成文件冲突（改为重新生成这些文件）。

前置条件

• 包含暂停中合并的仓库检出，或两个分支名称加上自行运行合并的权限。
• 双方的意图来源：看板完成摘要（terminal 运行 hermes kanban show <task-id>）、PR 正文，或至少每个分支的提交信息。
• 项目的构建/测试命令（如果存在）。

如何运行

独立模式——人类（或智能体）在存在冲突的仓库内调用此技能：加载技能，然后自上而下遵循「流程」。

生成的立智能体——多智能体作业中的首选形态：

• delegate_task：生成一个子智能体，其任务消息中包含仓库路径、两个分支名称，以及双方意图摘要的原文，并附上遵循本技能的指令。
• 看板原生方式：创建一个协调卡片，分配给第三个配置档（不是任一工作者的配置档），并将两个冲突卡片都链接为父级—— kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])。父级链接会自动将双方的完成摘要带入协调者的上下文；卡片正文应指明仓库路径和两个分支。

快速参考

冲突块类别	定义	解决方案
disjoint-intent（意图不相交）	两项改动服务于不同目标，可共存	合并两者
same-question-different-answer（同一问题、不同答案）	双方对同一个设计问题给出了不同答案	根据声明的意图选择其中一个；将决策显式呈现
superseded（已被取代）	一方的假设在对方改动后不再成立	保留存活的一方；说明原因

公正性契约：绝不偏袒生成你的一方；只触碰发生冲突的区域（不得顺手做无关编辑）；每一个设计问题的选择都必须在交接摘要中明确出现。

流程

1. 收集双方信息

• 通过 terminal 运行：git status（确认冲突状态并列出冲突文件）、git merge-base <A> <B>，然后对每一方运行 git log --oneline <base>..<side> 以及针对每个冲突文件的 git diff <base>..<side> -- <file>。在暂停的合并中，HEAD 是一方，MERGE_HEAD 是另一方。
• 收集每一方的意图：用 hermes kanban show <task-id> 获取完成摘要/元数据，或 PR 正文，或上述日志中的提交信息。在触碰任何文件之前，为每一方写下one句意图。
• 完成标准：你能用自己的话陈述双方的意图，并拥有每个冲突文件的双方 diff。

2. 对每个冲突块分类

• 用 read_file 打开每个冲突文件，定位每一个 <<<<<<</=======/>>>>>>> 块。
• 依据声明的意图——而不是哪项改动看起来更顺眼——为每个块推断快速参考表中恰好一个类别。
• 如果单个块包含多个独立决策（例如，可以干净合并的新逻辑，加之双方对样式/取整给出了不同选择），将其分解为子决策并分别分类。
• 单个文件常常混合多种类别：一个块可能是设计冲突，而相邻块是意图不相交的。按块分类，而非按文件。
• 完成标准：每个块都有成文的类别和一行理由。

3. 在公正性契约下解决

• 用 patch（或用于整文件重写的 write_file）编辑每个块：
  • disjoint-intent → 合并两项改动，使每个意图都得到充分满足。
  • same-question-different-answer → 选择最能服务于声明意图的答案（例如，如果任务要求正确性，则「严格校验」的意图胜过「快速默认」）。绝不将差异折中为双方都没要求的混合产物。
  • superseded → 保留存活的一方；删除已失效的假设前提。
• 绝不偏袒生成你的一方。如果意图确实势均力敌，升级处理（阻塞看板卡片/回传报告）而非猜测。
• 冲突标记之外不做任何改动——不格式化、不改名，也不做顺势修复。
• 通过 terminal 对每个已解决文件执行 git add。
• 完成标准：search_files 在仓库中找不到任何 <<<<<<< 标记，且每个已解决文件都已暂存。

4. 验证

• 通过 terminal 运行项目的构建/测试；至少导入/执行改动过的模块。两个意图都必须在合并后的行为中可观察到（例如，A 方的新语义与 B 方意图不相交的新增内容同时存在）。
• 完成合并：git commit（默认合并信息外加列出各块决策的正文即可）。
• 完成标准：验证通过且合并提交已存在。

5. 交接

• 产出一份完成摘要，列出每一个冲突块的决策： file:lines — class — which side(s) kept — rationale。对于每一个 same-question-different-answer 块，说明该设计问题以及你所选择的答案，以便人类可以否决它——绝不埋没任何设计决策。
• 看板：kanban_complete(summary=...)。独立模式：打印该摘要。
• 完成标准：摘要已交付并列出所有冲突块。

陷阱

• 偏袒自己：如果你是由冲突的某一方智能体生成的，你在结构上就有偏差——明确说明这一点，并在权衡时有意考虑另一方的意图。优先采用第三方配置档的形态，这样此问题就永远不会出现。
• 在设计冲突上折中会产生无人设计过的混合产物；选择一个答案并显式呈现。
• 按文件分类：文件通常混合多种块类别；将整个文件归为一类会悄悄丢掉一项意图不相交的改动。
• 顺手编辑会使合并无法审查，并从原始智能体那里夺走本属于它们的决策。
• 意图缺失：仅凭提交信息可能过于单薄；优先采用看板完成摘要或 PR 正文。如果双方的意图都无从还原，升级处理而非猜测。
• 屡犯问题：跨轮次在同一文件上反复出现的冲突是热点信号，而非例行协调工作——对其加以标记（例如一条 hotspot: <path> — <reason> 看板评论），以便编排器拆解该文件，而不是对其次第出现的每一次新碰撞逐一协调。

验证

• git status 显示目标分支上的工作树已清理干净，并存在一次合并提交。
• 不再残留任何冲突标记（search_files 模式 <<<<<<<）。
• 构建/测试通过；双方的意图可被明显观察到，或被丢弃的一方在摘要中被明确指出。
• 交接摘要逐一列举每个冲突块及其类别和理由。