用途：在 git 合并或变基发生冲突时，安全地解决冲突而不丢失任何一方原本想实现的改动，适用于任何能够提交变更的智能体。
核心原则：冲突不是简单的选择 ours 或 theirs，而是意图协调问题。必须先理解双方改动各自想达到什么目的，再决定如何解决；正确的做法往往是保留双方意图，通过手动编辑合并或重构内容。若两种意图确实互相矛盾、无法同时成立，应询问用户如何取舍，不要凭空捏造新意图。
主要规则：解决前先分析双方意图，区分兼容部分与矛盾部分；意图不明确时向用户提问直到清楚，不得猜测。必须通过编辑冲突文件来解决，而非盲目执行 git checkout --ours / --theirs 或直接删除段落。解决后要确认没有残留冲突标记（<<<<<<<、=======、>>>>>>>），确认 scripts/git-status.sh 显示没有未合并路径，并核实结果保留双方意图。
使用方式：先用 scripts/git-status.sh 或 git diff --name-only --diff-filter=U 确认冲突文件；注意 merge 与 rebase 下 ours/theirs 语义不同，rebase 时应优先阅读冲突标记；用 sed -n '1,200p' 查看冲突片段，可用 git show :2:<file>、git show :3:<file> 对比索引阶段；在聊天中按模板输出冲突分析（双方意图、兼容性、拟定方案、待答问题）；编辑文件合并双方意图并清除标记；用 scripts/git-diff.sh 复核即将提交的内容。若冲突涉及 source-of-truth 文档（如 docs/spec.md、docs/architecture.md）且正确内容不明确，必须先问维护者。
提交要求：解决冲突的提交信息需说明哪些文件冲突、如何解决（如合并双方意图、保留 X 并调整 Y、用户选择 A）以及为何这样能保留预期行为或文档。
限制：无法可靠判断双方意图时应停下提问，宁可不猜；提交前必须审阅最终 diff；有些意图本质矛盾，需用户决策而无法自动解决。