用途：当两个智能体的分支或工作树在并行任务（看板流水线、并行 PR、多工作树重构）中发生 git 合并冲突，且任何一方都不应自行裁决时，由中立的第三方按双方声明的意图完成合并。不适用于单个智能体自身工作内的冲突，也不适用于锁文件或生成文件的琐碎冲突（应直接重新生成）。
主要能力：按 hunk 分类处理冲突。disjoint-intent（双方目标不同且可共存）合并两者；same-question-different-answer（同一设计问题答案不同）依据声明的意图择一，并显式暴露该决策；superseded（一方前提在另一方改动后不再成立）保留存活方并说明原因。中立性契约要求：不偏袒生成自己的那一方，只改动冲突区域，不做顺手修改，所有设计取舍必须写入交接摘要。
使用方式：可在冲突仓库中由人或智能体直接加载技能并按流程执行；多智能体场景推荐派生中立子智能体，任务消息中给出仓库路径、两个分支名和双方意图摘要；看板原生方式为创建分配给第三方 profile 的协调卡片，并把两张冲突卡片作为父任务链接，使双方完成摘要自动进入上下文。流程为：收集双方信息（git status、git merge-base <A> <B>、git log --oneline <base>..<side>、git diff <base>..<side> -- <file>，以及看板完成摘要、PR 正文或提交信息）；逐 hunk 分类；在契约下用 patch 或 write_file 解决并 git add；运行构建/测试验证；最后输出逐 hunk 决策摘要（文件:行 — 类别 — 保留方 — 理由），看板用 kanban_complete(summary=...)，独立运行则打印摘要。
限制与注意：意图缺失时提交信息可能过于单薄，应优先看板摘要或 PR 正文，无法恢复意图时应升级而非猜测；同一文件反复冲突是热点信号，应标记并让编排者拆分该文件；设计冲突不可折中成双方都未设计的混合方案；若由冲突一方派生，存在结构性偏见，应说明并刻意权衡另一方意图。