| name | patch-adaptation-review |
| description | 审查适配的补丁以验证它们是否忠实地代表了原始更改。
当比较PR或上游提交与本地适配版本时，当验证补丁适配用于反向移植时，
或当审查任何补丁被修改以适应不同代码库版本的情况时，使用此技能。
当用户提到"适配补丁"、"补丁审查"、"比较提交"、"验证反向移植"、
"检查补丁等价性"、"验证backport"、"对比commit差异"、"审查适配质量"，
或要求审查PR和本地提交之间的更改时触发此技能。
此技能也可在 patch-porting 阶段2循环中自动调用，对冲突解决后的补丁进行深度审查。
|
| license | MIT |
| compatibility | opencode, claude |
| metadata | {"audience":"developers","workflow":"git","category":"git"} |
补丁适配审查
帮助审查适配的补丁，确保它们保留了原始更改的意图和功能。
何时使用此技能
在以下情况下使用此技能：
- 来自PR或上游提交的补丁被适配以适应不同的代码库版本
- 需要验证适配是否保留了原始修复/功能
- 比较原始提交与本地适配版本
- 审查需要修改的反向移植补丁
输入要求
此技能接受以下输入格式之一：
- PR URL + 提交哈希: "审查提交abc123中PR #123的适配"
- 两个提交哈希: "比较原始提交def456与适配提交abc123"
- 仅PR URL: "审查PR #123是如何被适配的"（使用HEAD作为适配版本）
工作流程
步骤 1: 收集信息
从用户的请求中提取信息：
- 识别原始补丁来源（PR URL或提交哈希）
- 识别适配版本（提交哈希或HEAD）
- 如果不清楚，请用户澄清
步骤 2: 提取差异
对于原始和适配的提交：
git show --stat <commit>
git log -1 --format="%H %s" <commit>
git diff <commit>^..<commit>
对于PR URL，使用 ag-cli：
ag-cli pr view <owner/repo> <PR-number>
或使用 Git 原生方法获取 PR 提交列表：
git log --all --grep="!<PR-number>" --oneline
步骤 3: 比较和分析
系统地比较以下方面：
1. 文件覆盖范围
- 从两个差异中提取文件列表
- 检查适配版本中是否修改了所有原始文件
- 注意适配中的任何额外文件
- 通过条件: 文件列表匹配，或适配仅添加必要的上下文文件
2. 功能等价性
- 识别原始补丁的作用（修复、功能、重构）
- 检查适配补丁是否修改了相似的代码部分
- 验证核心逻辑是否保留
- 通过条件: 尽管代码有差异，但核心功能得以维持
3. 代码上下文保留
- 比较更改周围的上下文行
- 检查修改是否针对相同的函数/代码块
- 验证更改是否在正确的位置（行号可以不同）
- 通过条件: 更改针对适配代码库中的正确位置
4. 依赖和导入
- 检查是否添加了所需的导入/头文件
- 验证依赖更改是否等价
- 注意include语句的任何差异
- 通过条件: 依赖正确适配到本地代码库
5. 边缘情况和错误处理
- 比较错误处理路径
- 检查边界条件处理
- 验证清理/资源管理
- 通过条件: 错误处理逻辑得以保留
步骤 4: 生成报告
创建结构化的检查清单报告：
# 补丁适配审查报告
## 摘要
- 原始: <短哈希> - <提交消息>
- 适配: <短哈希> - <提交消息>
- 总体: ✓ 通过 / ✗ 需要审查
## 详细检查清单
### 1. 文件覆盖范围 [✓/✗]
**结果**: 通过 / 需要审查
**详情**:
- 原始修改: file1.c, file2.h, file3.c
- 适配修改: file1.c, file2.h, file3.c
- [任何差异或说明]
### 2. 功能等价性 [✓/✗]
**结果**: 通过 / 需要审查
**详情**:
- 原始: [它的作用]
- 适配: [它的作用]
- [等价性分析]
### 3. 代码上下文保留 [✓/✗]
**结果**: 通过 / 需要审查
**详情**:
- [上下文比较]
- [位置分析]
### 4. 依赖和导入 [✓/✗]
**结果**: 通过 / 需要审查
**详情**:
- [导入/依赖比较]
### 5. 边缘情况和错误处理 [✓/✗]
**结果**: 通过 / 需要审查
**详情**:
- [错误处理比较]
## 建议
- [列出需要人工审查的项目]
- [总体评估]
- [如需要的建议操作]
分析指南
处理差异
在比较差异时，规范化以下内容：
- 空白差异: 忽略空格更改
- 行号差异: 由于代码库分歧而预期会有差异
- 变量命名: 如果代码库使用不同的约定，可能会有差异
- 上下文长度: 不同版本可能有不同的周围代码
需要标记的内容
在以下情况下标记为需要人工审查：
- 核心功能看起来不同
- 适配中缺少文件
- 错误处理被删除或显著更改
- 依赖缺失
- 逻辑流程被更改
可接受的内容
在以下情况下接受为等价：
- 相同的逻辑更改，不同的行号
- 相同的修复应用于略有不同的代码结构
- 添加了额外的防御性检查
- 适配到不同的API/函数名
- 修改了额外的上下文文件（如果合理）
使用示例
示例 1: PR + 提交
用户: "审查提交abc123def中PR #456是如何被适配的"
技能响应:
"我将审查补丁适配。让我获取PR提交并与提交abc123def进行比较..."
[提取并比较]
"# 补丁适配审查报告
## 摘要
- 原始: 789abc1 - 修复设备注册中的竞态条件
- 适配: abc123def - 修复设备注册中的竞态条件（已适配）
- 总体: ✓ 通过
## 详细检查清单
### 1. 文件覆盖范围 ✓
**结果**: 通过
**详情**: 两个补丁都修改了:
- drivers/net/ethernet/intel/e1000/e1000_main.c
- include/linux/netdevice.h
文件列表完全匹配。
### 2. 功能等价性 ✓
**结果**: 通过
**详情**: 两个补丁都在设备注册前添加了自旋锁以防止竞态条件。
核心逻辑保留: 锁获取 -> 注册 -> 锁释放。
### 3. 代码上下文保留 ✓
**结果**: 通过
**详情**: 原始在第1234行修改register_netdevice()。
适配在第1256行修改相同的函数（代码库版本差异）。
上下文是等价的。
### 4. 依赖和导入 ✓
**结果**: 通过
**详情**: 两者都添加了 #include <linux/spinlock.h>
依赖正确保留。
### 5. 边缘情况和错误处理 ✓
**结果**: 通过
**详情**: 两者以相同的方式处理锁获取失败。
错误路径保留。
## 建议
- 补丁适配看起来正确
- 可以安全合并"
示例 2: 两个提交
用户: "比较原始提交def456与适配提交abc123"
[类似的分析和报告]
有效审查的技巧
- 理解意图: 阅读提交消息以了解补丁应该做什么
- 先检查diffstat: 快速了解更改的文件
- 关注逻辑: 行号和确切文本不如逻辑更改重要
- 考虑代码库上下文: 由于版本差异，适配可能合理地不同
- 要彻底但务实: 标记真正的问题，不要挑剔无害的差异
输出
始终提供：
- 每个检查清单项目的明确通过/失败
- 关于比较内容的具体细节
- 可操作的建议
- 补丁质量的总体评估
