{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Agent Merge Conflict Arbiter

两个 agent 间合并冲突的中立仲裁者。

Skill 元数据

参考：完整 SKILL.md

Agent 合并冲突仲裁者

作为公正第三方解决两个 agent 分支间的 git 合并冲突。agent 对照对端工作解决冲突时，可靠地要么覆盖对端、要么放弃自己的变更——它们缺对端上下文，且偏向己方。本 skill 是修复：一个中立和解者，接收两个 diff 加双方声明意图，产出合并结果，像合并队列仲裁者。

何时使用

• 两个 agent 分支/worktree 在并行战役中碰撞（看板工程流水线、并行 PR 波、多 worktree 重构）。
• git merge 或 git rebase 在两个 agent 工作间的冲突处停下，且任一个原始 agent 都不应自裁。
• 不要用于单一 agent 自己工作内的冲突，或琐碎 lockfile/生成文件冲突（那些重新生成）。

前置条件

• 含停下的 merge 的仓库检出，或两个分支名加你自己跑 merge 的权限。
• 双方意图来源：看板完成摘要（terminal 跑 hermes kanban show <task-id>）、PR 正文，或至少每分支的 commit 消息。
• 项目的构建/测试命令（若有）。

运行方式

独立——人（或 agent）在冲突仓库内调用本 skill：加载 skill，然后自上而下跟流程。

派发的中立 agent——多 agent 战役的首选形态：

• delegate_task：派一个子代理，其任务消息逐字含仓库路径、两个分支名和双方意图摘要，加遵循本 skill 的指令。
• 看板原生：创建一张和解卡，指派给第三个 profile（非任一 worker profile），两张冲突卡都链接为父——kanban_create(title="reconcile branch-a x branch-b", assignee="reconciler", parents=["t_a", "t_b"])。父链接自动把双方完成摘要带进和解者上下文；卡正文应命名仓库路径和两个分支。

快速参考

公正契约：绝不偏向派发你的一方；只碰冲突区域（不顺手编辑）；每个设计问题选择必须显式出现在交还摘要里。

流程

1. 收集双方

• 经 terminal 跑：git status（确认冲突状态并列出冲突文件）、git merge-base <A> <B>，然后对每方 git log --oneline <base>..<side>，对每个冲突文件 git diff <base>..<side> -- <file>。在停下的 merge 中，HEAD 是一方，MERGE_HEAD 是另一方。
• 收集每方意图：hermes kanban show <task-id> 拿完成摘要/元数据，或 PR 正文，或上面日志的 commit 消息。碰任何文件前写下每方一句意图。
• 完成当：你能用自己的话说出双方意图，且每个冲突文件都有两个 diff。

2. 分类每个冲突 hunk

• 用 read_file 打开每个冲突文件，定位每个 <<<<<<</=======/>>>>>>> 块。
• 按快速参考表给每个 hunk 恰好一个类，依据声明意图判断——不依据哪个变更看着更好。
• 若单个 hunk 含多个独立决定（如干净合并的新逻辑，加一个双方答得不同的样式/取舍），分解成子决定，每个分类。
• 单文件常混合类：一个 hunk 是设计碰撞，相邻 hunk 可能 disjoint。按 hunk 分类，不按文件。
• 完成当：每个 hunk 有写下的类和一行理由。

3. 在公正契约下解决

• 用 patch 编辑每个 hunk（整文件重写用 write_file）：
  • disjoint-intent → 合并两变更，使每个意图完全服务。
  • same-question-different-answer → 选最服务声明意图的答案（如任务要求正确性时，"严格验证"意图胜"快速默认"）。绝不把差别折成双方都没要的混合。
  • superseded → 保留存活方；删死掉前提。
• 绝不偏向派发你的一方。若意图真平局，升级（阻塞看板卡/回报）而非猜。
• 不改冲突标记外任何东西——无格式、重命名或机会修复。
• 经 terminal 对每个解决文件 git add。
• 完成当：search_files 在仓库找不到 <<<<<<< 标记，且每个解决文件已暂存。

4. 验证

• 经 terminal 跑项目构建/测试；至少导入/执行触及模块。两个意图必须在合并行为中可观察（如 A 方新语义和 B 方 disjoint 增量都在）。
• 完成 merge：git commit（默认 merge 消息加列 hunk 决定的正文即可）。
• 完成当：验证通过且 merge commit 存在。

5. 交还

• 产出完成摘要，命名每个 hunk 决定：file:lines — 类 — 保留哪方 — 理由。对每个 same-question-different-answer hunk，说明设计问题和你选的答案，让人可否决——绝不埋设计决定。
• 看板：kanban_complete(summary=...)。独立：打印摘要。
• 完成当：摘要已交付且列出所有 hunk。

常见陷阱

• 自偏向：若你由冲突 agent 之一派发，你结构上有偏——声明这点，刻意权衡另一方意图。优先第三 profile 形态，使这永不出现。
• 在设计碰撞上折中产生没人设计的混合；选一个答案并亮出。
• 按文件分类：文件通常混合 hunk 类；把整文件归一类会静默丢掉 disjoint 变更。
• 顺手编辑使 merge 不可评审，并从原始 agent 偷走决定。
• 缺意图：commit 消息本身可能薄；优先看板完成摘要或 PR 正文。若双方意图都不可恢复，升级而非猜。
• 惯犯：同一文件跨轮重复冲突是热点信号，而非常规和解工作——标记它（如 hotspot: <path> — <reason> 看板评论），让编排者分解该文件，而非串行和解其上每个新碰撞。

验证

• git status 显示目标分支干净树，带 merge commit。
• 无冲突标记残留（search_files 模式 <<<<<<<）。
• 构建/测试通过；双方意图可证明存在，或被丢弃的一方在摘要中显式命名。
• 交还摘要枚举每个 hunk，带类和理由。