conflict-resolver-zh

name	conflict-resolver-zh
description	把 merge/rebase 冲突块用中文讲清"两边各想干啥",引导解决而不自动改文件。当用户说「帮我看冲突 / 解冲突 / 合并冲突在哪 / conflict 怎么改」时触发。

conflict-resolver-zh — 冲突中文解读与引导

把 git merge / git rebase 产生的冲突块用中文逐条讲清——ours 想做什么、theirs 想做什么、冲突点在哪、建议怎么合——然后等用户确认,再给出合并后的内容让用户自己应用。不自动改任何文件。

何时触发

• 用户说"帮我看冲突"、"解冲突"、"合并冲突在哪"、"conflict 怎么改"
• 用户说"我 merge/rebase 有冲突"、"<<<<<<< HEAD 是什么意思"
• 用户粘贴了包含 <<<<<<< / ======= / >>>>>>> 的内容
• 用户说"冲突太多不知道从哪改"

工作流

1. 列出冲突文件与冲突块

在仓库目录执行脚本,列出所有冲突及内容:

bash <skill>/bin/list-conflicts.sh [目录,默认当前]

• 优先用 git diff --name-only --diff-filter=U 找冲突文件(精确)
• 若不在 git 仓库或无 git 命令,退而用 grep 扫 <<<<<<< 标记
• 输出每个文件里各冲突块的行号、ours(当前分支)内容、theirs(传入分支)内容
• 无冲突 → 输出"无冲突"并退出

2. 逐块用中文解读

对每一个冲突块,按以下结构分析并输出:

文件:<路径>  冲突块 #<n>(第 <起始行>–<结束行> 行)

【ours(当前分支)想做什么】
<用白话描述 ours 这段代码/内容的意图>

【theirs(传入分支)想做什么】
<用白话描述 theirs 这段代码/内容的意图>

【冲突点】
<两边修改了什么导致冲突,例如:都修改了同一个函数签名 / 都在同一行插入了不同内容>

【建议】
<三选一:保留 ours / 保留 theirs / 两段融合(给出融合思路)>
<若是语义冲突(都改了同一逻辑),明确提示:此处需人工核对,不能机械取一边>

3. 征得用户确认后给出合并内容

• 对每个冲突块,先问用户:"您倾向于保留哪边,还是需要融合?有什么业务背景可以补充?"
• 用户确认后,给出去掉冲突标记的合并内容(纯文本),由用户自行粘贴/应用。
• 不直接修改文件,不执行 git add,不执行任何写操作。

硬规则

1. 不臆断业务意图:拿不准 ours/theirs 在做什么时,直接问用户,不编造解释。
2. 语义冲突必须提醒人工核对:两边都修改了同一段逻辑(而不只是格式/空白差异)时,明确标注"语义冲突,建议人工核对",不能机械取一边。
3. 代码/冲突内容保留原文:引用冲突块时原样展示,不擅自格式化或翻译代码。
4. 不自动解决冲突:无论把握多大,都等用户明确确认后再给出最终内容。
5. 不做任何 git 写操作:不执行 git add、git commit、git checkout、文件写入等操作。
6. 优先讲清分歧,再给建议:先让用户理解两边各做了什么,再给合并方向,避免用户盲目接受建议。

边界

• 只处理文本格式的 git 冲突标记(<<<<<<< / ======= / >>>>>>>),二进制冲突无法解读。
• 不替代代码审查;若冲突涉及复杂逻辑,建议用户找相关模块的负责人确认。
• 不联网、不查提交历史(只看当前文件内容)。
• 不保证建议 100% 正确;用户需自行验证合并结果的正确性(跑测试、人工检查)。