roo-conflict-resolution

用途

该技能用于智能解决 Git 合并冲突。当任务涉及以下场景时适用：解决某个 Pull Request 的合并冲突、对与目标分支存在冲突的分支执行 rebase、理解和分析相互冲突的代码改动、就保留/合并/舍弃哪些改动做出智能判断、利用 git 历史辅助冲突解决决策。

不适用场景：没有合并冲突需要解决时、不涉及冲突的普通代码审查、处理没有任何合并场景的全新代码时。

主要能力

该技能通过分析 git 历史、提交信息和代码改动来做出智能解决决策。给定一个 PR 编号（例如 "#123"），它会处理完整的冲突解决流程。

初始化步骤：

解析 PR 编号：从形如 "#123" 或 "PR #123" 的输入中提取 PR 编号并校验。
获取 PR 信息：gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName，获取 PR 标题与描述以理解意图，并确定源分支与目标分支。
检出 PR 分支并准备 rebase：
- gh pr checkout [PR_NUMBER] --force（强制检出，确保干净状态）
- git fetch origin main（拉取最新 main 分支）
- GIT_EDITOR=true git rebase origin/main（非交互式 rebase 以暴露冲突）
检查合并冲突：
- git status --porcelain
- git diff --name-only --diff-filter=U 识别带冲突标记（'UU'）的文件，生成待解决文件清单。

主要工作流阶段：

阶段 1 冲突分析：读取冲突文件识别冲突标记，提取 <<<<<<< 与 >>>>>>> 之间的冲突片段，对冲突双方运行 git blame，获取相关提交的提交信息与 diff，分析每处改动背后的意图。
阶段 2 解决策略：按意图对改动分类（bugfix、feature、refactor 等），评估改动的新旧程度与相关性，检查是结构性重叠还是格式差异，判断改动能否合并或一方应覆盖另一方，并考虑测试更新及相关改动。
阶段 3 冲突解决：对每处冲突应用所选策略，在 diff 中正确转义冲突标记，校验解决后的代码语法正确，用 git add 暂存已解决文件。
阶段 4 校验：运行 git status 确认所有冲突已解决，检查编译或语法错误，审阅最终 diff，准备解决决策摘要。

使用方式

以 PR 编号为输入，按上述初始化步骤和四个阶段推进，过程中使用以下 git 命令：

命令	用途
`gh pr checkout [PR_NUMBER] --force`	强制检出 PR 分支
`git fetch origin main`	获取最新 main 分支
`GIT_EDITOR=true git rebase origin/main`	将当前分支 rebase 到 main（非交互）
`git blame -L [start],[end] [commit] -- [file]`	获取指定行的提交信息
`git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]`	获取提交元数据
`git show [sha] -- [file]`	获取某提交在指定文件上的实际改动
`git ls-files -u`	列出带暂存区信息的未合并文件
`GIT_EDITOR=true git rebase --continue`	解决冲突后继续 rebase

最佳实践：基于意图解决（高优先级，优先理解改动意图而非仅看代码差异；例如 bugfix 与 refactor 冲突时，在重构后的结构内应用修复逻辑）；保留所有有价值的改动（高优先级，尽量合并双方非冲突改动）；转义冲突标记（高优先级，使用 apply_diff 时用反斜杠转义，正确写法 \<<<<<<< HEAD，错误写法 <<<<<<< HEAD）；考虑相关改动（中优先级，关注测试、文档或依赖代码中的关联改动）。

解决启发式规则：bugfix 与 feature 冲突时，bugfix 一般优先（例外：feature 已包含该修复）；新旧改动冲突时，较新改动通常更相关（例外：较旧改动是安全补丁）；带测试更新的改动可能更完整；逻辑改动优先于格式改动。

适用场景与限制

适用场景如前文用途所述，围绕 PR 合并冲突与 rebase 冲突处理。

常见陷阱：盲目选择一方（可能丢失重要改动或引入回归，应始终用 git blame 与提交历史分析双方）；忽略 PR 上下文（PR 描述常解释改动原因，解决前应先获取并阅读 PR 信息）；未校验解决后的代码（可能语法错误或逻辑错误，始终检查语法错误并审阅最终 diff）；diff 中未转义的冲突标记（<<<<<<<、=======、>>>>>>> 会被当作 diff 语法解析，出现在内容中时须用反斜杠转义）。

apply_diff 示例：

<<<<<<< SEARCH
:start_line:45
-------
\<<<<<<< HEAD
function oldImplementation() {
  return "old";
}
\=======
function newImplementation() {
  return "new";
}
\>>>>>>> feature-branch
=======
function mergedImplementation() {
  // Combining both approaches
  return "merged";
}
>>>>>>> REPLACE

质量清单：解决前获取 PR 标题与描述、识别所有冲突文件、理解整体合并改动；解决中对冲突片段运行 git blame、阅读提交信息获取意图、考虑改动能否合并、在 diff 中转义冲突标记；解决后确认无残留冲突标记、检查语法/编译错误、审阅完整 diff、记录解决决策。

完成标准：所有合并冲突已解决、已解决文件已暂存、解决后的代码无语法错误、解决决策已记录。

沟通规范：说明解决决策时直接且技术化，聚焦每处冲突解决的依据，清晰总结合并了什么及为什么。进度更新格式为：Conflict in [file]: - HEAD: [改动简述] - Incoming: [改动简述] - Resolution: [决定内容及原因]。完成消息格式为：Successfully resolved merge conflicts for PR #[number] "[title]"，并附 Resolution Summary 与关键决策说明（如有），最后说明所有冲突已解决且文件已暂存待提交。

技能介绍

用途

主要能力

使用方式

适用场景与限制