用途
lgnh-resolve-conflict 用于在执行 Git rebase 或 merge 时解决代码冲突。它的目标不是简单挑一边，而是深入理解每个分支原本想做什么，产出一个既保留双方意图、又保持语法正确的解决方案。技能面向希望由 AI 辅助完成冲突处理、但仍需保留人工判断的开发者。
核心原则
- 先理解再操作：在弄清冲突为何发生、双方各自意图之前不解决冲突。
- 有歧义就问：当两个分支对同一逻辑做了有意的竞争性修改，且不清楚该选哪边或如何合并时，停止并询问用户，不猜测、不静默选边。
- 默认不提交：解决冲突后只暂存文件，除非用户明确要求，否则不执行提交，也不运行
git rebase --continue/git merge --continue，而是告诉用户下一步该运行什么。
主要能力与流程
第 1 步：评估现状
运行 git status 判断当前情况：
- 正在 rebase：存在
.git/rebase-merge/或.git/rebase-apply/ - 正在 merge：存在
.git/MERGE_HEAD - 两者都不是：没有进行中的冲突操作，告知用户并停止
同时找出所有冲突文件（git status 中显示为 both modified 或 Unmerged paths 的文件）。
第 2 步：理解各分支上下文
Rebase 场景下读取要变基到的目标分支、正在重放的提交，以及目标分支上与冲突文件相关的变更；Merge 场景下分别查看当前分支与待合并分支对冲突文件的改动。
第 3 步：分析每个冲突文件
- 用
git diff -- <file>查看原始冲突状态，定位所有<<<<<<<与>>>>>>>之间的冲突区域。 - 用
git show :2:<file>（ours）、git show :3:<file>（theirs）、git show :1:<file>（base）做三方对比，弄清基线版本、双方各自改了什么以及为什么改。 - 将冲突区域分类：非重叠（合并双方改动）、互补（选更好的或合并，不清楚时询问）、竞争（询问用户）、单边（采用有意义的改动）。
第 4 步：解决
编辑文件生成正确结果，要求保留双方意图、保持语法正确、不残留冲突标记、与文件及代码库其余部分一致，然后用 git add <file> 暂存。
第 5 步：验证与报告
- 用
git diff --check --cached确认无冲突标记，用git status确认无未合并路径。 - 必须运行项目的 lint 与类型检查；失败则修复并重跑，直至通过。若项目没有相关配置，需在摘要中明确说明。
- 输出冲突解决摘要，包括操作类型、基线分支、来源、每个文件的 ours/theirs/解决方式，以及建议的下一步命令。
使用方式
技能以对话方式工作：用户提出解决冲突的需求后，技能按上述步骤自行执行 Git 命令与分析，在需要业务判断时向用户提问，最后给出摘要和下一步操作建议。
适用场景
- 多人协作中 rebase 或 merge 出现代码冲突
- 希望保留双方改动意图而非简单取舍
- 需要冲突解决后自动做 lint 与类型检查把关
限制与注意事项
- 不会自动提交或继续 rebase/merge，需要用户手动执行后续命令。
- 遇到竞争性逻辑修改无法判断时会中断并询问，不会强行给出结果。
- ours/theirs 在 merge 与 rebase 中含义相反，需通过提交哈希确认。
- 若 base 版本读取失败，可能是双方都新增了该文件，此时将两版都视为全新内容并逻辑合并。
- 若项目未配置 lint 或类型检查，技能会明确说明而非静默跳过。
- 关于收费、平台与详细安装方式，资料暂未提供。