conflict-resolver-zhlisted

# conflict-resolver-zh — 冲突中文解读与引导 把 `git merge` / `git rebase` 产生的冲突块用中文逐条讲清——ours 想做什么、theirs 想做什么、冲突点在哪、建议怎么合——然后等用户确认,再给出合并后的内容让用户自己应用。**不自动改任何文件。** ## 何时触发 - 用户说"帮我看冲突"、"解冲突"、"合并冲突在哪"、"conflict 怎么改" - 用户说"我 merge/rebase 有冲突"、"`<<<<<<< HEAD` 是什么意思" - 用户粘贴了包含 `<<<<<<<` / `=======` / `>>>>>>>` 的内容 - 用户说"冲突太多不知道从哪改" ## 工作流 ### 1. 列出冲突文件与冲突块 在仓库目录执行脚本,列出所有冲突及内容: ```bash 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 冲突标记(`<<<<<<<` / `=======` / `>>>>>>>`),二进制冲突无法解读。 - 不替代代码审查;若冲突涉及复杂逻辑,建议用户找相关模块的负责人确