Conflict resolver zh

Skill YuAICode/ai-skills/skills/conflict-resolver-zh

35 个即用 Claude Code skill,每个都带离线测试 + skill-doctor 自校验 · 35 tested, self-linted Claude Code skills (中文优先)

Install

npx -y skills add YuAICode/ai-skills --skill conflict-resolver-zh

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

3.4 KB, as published. Nobody here has run it

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,不执行任何写操作。

硬规则

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

边界

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