用途：在 git merge、git rebase 或 git cherry-pick 已进行、且存在 unmerged 文件时启用。它只解决文本与行为层面的冲突，不替用户决定哪个分支应在产品层面获胜，后者属于发起集成者的业务决策。
主要流程：先检查操作状态、涉及的 branch/commit 与 unmerged 文件；对每个冲突 hunk 还原双方意图而非只看字面文本；将冲突分类为文本（同一行不同内容）、结构（同一函数/块被重排）、语义（无冲突标记但行为不兼容，如一侧改了签名、另一侧 caller 未适配）或生成文件（lockfile、构建产物）；在意图兼容时构造同时保留双方意图的结果；真正不可兼容时按集成目标（spec/issue）取舍并记录被放弃的 trade-off；清除所有冲突标记，做语法/解析校验，对改动文件运行 lint、typecheck；继续 git merge --continue 或 git rebase --continue，并在发布前跑相关回归测试。
关键约定：不要图方便批量使用 git checkout --ours/--theirs 或 -X ours/-X theirs；不要直接编辑生成文件而不更新源并重新生成；双方不冲突时应保留 schema、migration、测试与 API 契约改动；即使文件无冲突标记，也要复查 import、重命名与调用；不要借解决冲突做额外重构；未经明确要求不要用 --abort、force push 或破坏性 reset。
验证：git status 无 unmerged 文件，工作区 grep 无残留 <<<<<<<；逐 hunk 对照双方还原出的意图审查合并 diff；运行 typecheck、build、聚焦测试与相关回归套件；历史被重写时确认推送目标与方式。
限制与边界：该技能不裁决业务层面谁应获胜；与 $specsfy-specialist-code-review 配合复查合并结果，语义冲突暴露领域建模不一致时可结合 $specsfy-specialist-domain-modeling，涉及 Gitflow 分支拓扑时由 $specsfy-specialist-gitflow 决定合并去向。具体安装命令与平台支持暂未提供。