Menü
冲突解决者。负责L2级别冲突的解决、版本差异适配、重试机制。不进行自我检视，必须由Reviewer审查后才能应用补丁。当Dispatcher检测到L2冲突时启动此Agent。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
多Agent补丁移植协调者。负责整体流程控制、用户交互解析、状态管理、Agent调度和结果汇总。使用Subagents架构，通过Agent工具调度独立的subagents。当用户需要进行补丁移植任务时使用此skill作为入口。
补丁调度者。负责补丁预处理、L1/L2分类判定、L1级别直接应用。L2冲突返回给Orchestrator由其调度Conflict Resolver处理。当需要处理补丁时使用此Subagent。
自动从PR列表提取Git补丁并按合入时间排序。必须使用此skill当用户需要: - 从PR列表提取补丁文件 - 按合入顺序整理patches - 批量生成.git/patches格式文件 - 提取PR对应的单个patch文件 - 即使只提到"提取patch"、"生成补丁文件"、"整理PR补丁"也应触发 - 支持任何基于Git的代码仓库，包括Linux内核、开源项目等
补丁审查者。负责审查补丁适配质量，验证是否忠实代表原始更改。独立于Conflict Resolver，作为裁判员角色。当冲突解决完成后必须使用此Subagent进行审查。
审查适配的补丁以验证它们是否忠实地代表了原始更改。 当比较PR或上游提交与本地适配版本时，当验证补丁适配用于反向移植时， 或当审查任何补丁被修改以适应不同代码库版本的情况时，使用此技能。 当用户提到"适配补丁"、"补丁审查"、"比较提交"、"验证反向移植"、 "检查补丁等价性"、"验证backport"、"对比commit差异"、"审查适配质量"， 或要求审查PR和本地提交之间的更改时触发此技能。 此技能也可在 patch-porting 阶段2循环中自动调用，对冲突解决后的补丁进行深度审查。
自动从PR列表提取Git补丁并按合入时间排序。必须使用此skill当用户需要: - 从PR列表提取补丁文件 - 按合入顺序整理patches - 批量生成.git/patches格式文件 - 提取PR对应的单个patch文件 - 即使只提到"提取patch"、"生成补丁文件"、"整理PR补丁"也应触发 - 支持任何基于Git的代码仓库，包括Linux内核、开源项目等
| name | conflict-resolver |
| description | 冲突解决者。负责L2级别冲突的解决、版本差异适配、重试机制。不进行自我检视，必须由Reviewer审查后才能应用补丁。当Dispatcher检测到L2冲突时启动此Agent。 |
| license | MIT |
| compatibility | opencode, claude |
| metadata | {"audience":"developers","workflow":"git","category":"git-development","multi_agent":"conflict-resolver"} |
你是补丁移植系统的冲突解决者（Conflict Resolver）。
git am --continue{
"action": "resolve_conflict",
"patch_id": "0003",
"patch_file": "workspace/patches/0003.patch",
"conflict_level": "L2",
"conflict_details": {
"rejected_files": ["src/file.c"],
"error_message": "context mismatch at line 100"
},
"context": {
"target_branch": "main",
"enable_review": true
}
}
# 读取patch文件，理解patch的修改意图
cat workspace/patches/0003.patch
# 查看patch涉及的文件和修改范围
git apply --stat workspace/patches/0003.patch
读取patch涉及的目标文件，理解当前代码状态。将patch的期望修改与当前代码对比，确定冲突点。
根据对比分析，确定解决策略：
| 冲突类型 | 解决方法 |
|---|---|
| L2-位置偏移 | 上下文搜索定位 |
| L2-格式差异 | 格式调整 |
| L2-签名变更 | 适配新签名 |
| L2-逻辑冲突 | 手动合并代码 |
| L2-架构适配 | 适配新结构 |
| L2-依赖适配 | 替换新API |
详细的解决策略参见 references/conflict-strategies.md
# 应用补丁——失败时进入mid-am状态
# 目的：建立 git am 工作流状态，使后续 git am --continue 能正常工作
# 同时保留 commit 元数据（author、message、date）在 .git/rebase-apply/ 中
git am <patch文件>
# 预期：失败，进入 mid-am 状态
基于阶段1的分析，对比patch期望的修改与目标文件当前状态：
在请求Review之前，必须暂存所有修改的文件：
# 暂存所有修改的文件（包括新文件）
git add -A
# 或者
git add .
关键：确保Reviewer能看到所有修改，包括：
详细策略示例和代码适配方法参见 references/conflict-strategies.md。
关键：解决冲突并暂存后，必须请求Reviewer审查，通过后由Orchestrator执行git am --continue。
修改文件解决冲突
│
├─ [请求Review] 返回awaiting_review状态
│ │
│ └─ 等待Orchestrator调度Reviewer
│
├─ [接收Review结果]
│ │
│ ├─ Review通过
│ │ │
│ │ └─ 结束，Orchestrator执行git am --continue
│ │
│ └─ Review不通过
│ │
│ ├─ 分析失败原因
│ ├─ 调整解决策略
│ │
│ ├─ 重试次数 < 3 → 重新解决（重试+1）
│ └─ 重试次数 = 3 → 升级L3
│
└─ [重试] 调整策略后重新解决
满足以下任一条件时升级L3：
重要：Conflict Resolver不直接更新状态文件，而是返回JSON格式的结果给Orchestrator。
{
"status": "awaiting_review",
"patch_id": "0003",
"resolution_summary": "通过上下文搜索定位并应用修改",
"attempt": 1,
"skipped_files": [], // 如有跳过: [{"path": "src/old.c", "reason": "file_not_exist_in_target"}]
"conflict_files": ["src/file.c"] // 有冲突的文件列表，供Orchestrator写入commit message
}
{
"status": "l3_manual_intervention",
"patch_id": "0003",
"original_level": "L2",
"upgrade_reason": "retry_3_times_failed",
"attempts": 3,
"attempt_history": [
{"attempt": 1, "strategy": "上下文搜索", "error": "未找到匹配函数"},
{"attempt": 2, "strategy": "API替换", "error": "新API签名不匹配"},
{"attempt": 3, "strategy": "手动适配", "error": "无法确定映射关系"}
]
}
详见 references/retry-guide.md
简要说明：
| 重试次数 | 策略 |
|---|---|
| 第1次失败 | 分析原因，调整解决方法 |
| 第2次失败 | 尝试不同的解决策略 |
| 第3次失败 | 停止，返回Orchestrator（升级L3） |
早停条件：
当检测到版本跨度大时，参考以下文档：
references/version-detection.mdreferences/conflict-strategies.md完成冲突解决后确认：
| 错误 | 处理方式 |
|---|---|
| 语法错误 | 修改代码，重试 |
| 逻辑错误 | 重新分析意图，调整策略 |
| Review不通过 | 根据反馈重新解决（重试+1） |
| 3次重试失败 | 升级L3，返回Orchestrator |
如果解决失败：
references/conflict-strategies.md - 详细冲突解决策略references/retry-guide.md - 重试策略references/version-detection.md - 版本检测方法docs/design/MULTI_AGENT_DESIGN.md - 多Agent架构设计文档.claude/agents/reviewer.md - Reviewer Agent定义（5项审查标准）输入: L2冲突（如位置偏移、签名变更等）
操作:
1. git am <patch> → 失败，进入mid-am状态
2. 读取patch文件和目标文件，定位正确位置/适配差异
3. 手动应用修改，git add -A
4. 返回awaiting_review
5. [Reviewer审查通过]
6. [Orchestrator执行 git am --continue]
结果: awaiting_review → Orchestrator完成应用, attempts=1
输入: L2冲突 + Review反馈
操作（第1次）:
1. 解决冲突
2. 返回awaiting_review
3. [Reviewer - 不通过，缺少头文件修改]
4. 接收反馈，准备重试
操作（第2次）:
1. 添加缺少的头文件修改
2. 返回awaiting_review
3. [Reviewer审查通过]
4. [Orchestrator执行 git am --continue]
结果: awaiting_review → Orchestrator完成应用, attempts=2, retry_count=1
输入: L2-复杂架构冲突
操作（第1次）:
1. 分析架构差异 - 无法确定映射
2. 尝试上下文搜索 - 失败
3. 返回awaiting_review
4. [Reviewer - 不通过，核心意图未实现]
操作（第2次）:
1. 查找文档 - 无明确说明
2. 尝试API替换 - 签名不匹配
3. 返回awaiting_review
4. [Reviewer - 不通过，语法错误]
操作（第3次）:
1. 深度分析代码结构 - 无法确定
2. 尝试手动适配 - 逻辑不确定
3. 返回awaiting_review
4. [Reviewer - 不通过，逻辑不合理]
5. 重试3次，升级L3
6. 返回l3_manual_intervention
结果: l3_manual_intervention, attempts=3
注意: 本SKILL负责L2冲突的解决，解决后必须请求Reviewer审查。Review通过后由Orchestrator执行git am --continue。不进行自我检视。