fix-review

修复审查

通过差异分析，验证提交是否解决了安全问题，同时没有引入错误。

适用场景

• 根据安全审计报告审查修复分支
• 验证修复提交是否确实解决了问题
• 检查特定问题（TOB-XXX 格式）是否已修复
• 分析提交范围内是否存在引入错误的模式
• 将代码变更与审计建议交叉核对

不适用场景

• 初始安全审计（使用 audit-context-building 或 differential-review）
• 没有特定基线或问题集的代码审查
• 没有先前审计的全新开发
• 仅涉及文档的变更

---

常见借口（不可跳过）

借口	错误原因	必须采取的行动
“提交说明说它修复了 TOB-XXX”	提交说明可能不实，代码才说明真相	验证实际代码变更是否解决了问题
“修复很小，不可能引入新错误”	小改动也可能造成大问题	分析所有变更，检查反模式
“我会检查重要问题”	所有问题都很重要	系统地检查每个问题
“测试通过了”	测试可能没有覆盖修复内容	验证修复逻辑，而不只是测试状态
“开发者是同一个人，他们了解代码”	熟悉也会造成盲点	对每项变更进行独立分析

---

快速参考

输入要求

输入	必需	格式
源提交	是	Git 提交哈希或引用（修复前的基线）
目标提交	是	一个或多个要分析的提交哈希
安全报告	否	本地路径、URL 或 Google Drive 链接

问题状态值

状态	含义
FIXED	代码变更直接解决了该问题
PARTIALLY_FIXED	已解决部分问题，其他问题仍然存在
NOT_ADDRESSED	未发现相关变更
CANNOT_DETERMINE	上下文不足，无法验证

---

工作流

阶段 1：收集输入

向用户收集所需输入：

Source commit:  [hash/ref before fixes]
Target commit:  [hash/ref to analyze]
Report:         [optional: path, URL, or "none"]

如果用户提供了多个目标提交，请使用相同的源提交，分别处理每个目标提交。

阶段 2：获取报告

提供安全报告时，根据其格式获取报告：

本地文件（PDF、MD、JSON、HTML）： 使用 Read 工具直接读取文件。Claude 可原生处理 PDF。

URL： 使用 WebFetch 工具获取网页内容。

无法访问的 Google Drive URL： 使用 gdrive CLI 的 Google Drive 备用逻辑，请参阅 references/report-parsing.md。

阶段 3：提取问题

解析报告以提取问题：

Trail of Bits 格式：

• 查找“详细问题”部分
• 提取符合以下模式的问题：TOB-[A-Z]+-[0-9]+
• 收集：ID、标题、严重程度、描述、受影响的文件

其他格式：

• 编号的问题（问题 1、问题 2）
• 按严重程度划分的部分（严重、高、中、低）
• 包含 findings 数组的 JSON

详细的解析策略请参阅 references/report-parsing.md。

阶段 4：分析提交

针对每个目标提交，分析其提交范围：

# Get commit list from source to target
git log <source>..<target> --oneline

# Get full diff
git diff <source>..<target>

# Get changed files
git diff <source>..<target> --name-only

对于范围内的每个提交：

1. 检查差异，查找引入错误的模式
2. 检查安全反模式（请参阅 references/bug-detection.md）
3. 将变更对应到相关问题

阶段 5：验证问题

对于报告中的每个问题：

1. 识别相关提交 - 按以下内容进行匹配：

   • 问题中提及的文件路径
   • 问题描述中的函数／变量名称
   • 提交消息中引用的问题 ID

2. 验证修复 - 检查以下内容：

   • 是否解决了根本原因（而不只是表面症状）
   • 修复是否遵循报告中的建议
   • 是否引入了新的漏洞

3. 分配状态 - 根据证据进行判断：

   • FIXED：明确的代码更改解决了该问题
   • PARTIALLY_FIXED：部分方面已修复，其他方面仍未解决
   • NOT_ADDRESSED：没有相关更改
   • CANNOT_DETERMINE：需要更多背景信息

4. 记录证据 - 对于每个问题：

   • 解决该问题的提交哈希
   • 具体的文件和行更改
   • 修复如何解决根本原因

详细的匹配策略请参阅 references/finding-matching.md。

阶段 6：生成输出

生成两份输出：

1. 报告文件（FIX_REVIEW_REPORT.md）：

# Fix Review Report

**Source:** <commit>
**Target:** <commit>
**Report:** <path or "none">
**Date:** <date>

## Executive Summary

[Brief overview: X findings reviewed, Y fixed, Z concerns]

## Finding Status

| ID | Title | Severity | Status | Evidence |
|----|-------|----------|--------|----------|
| TOB-XXX-1 | Finding title | High | FIXED | abc123 |
| TOB-XXX-2 | Another finding | Medium | NOT_ADDRESSED | - |

## Bug Introduction Concerns

[Any potential bugs or regressions detected in the changes]

## Per-Commit Analysis

### Commit abc123: "Fix reentrancy in withdraw()"

**Files changed:** contracts/Vault.sol
**Findings addressed:** TOB-XXX-1
**Concerns:** None

[Detailed analysis]

## Recommendations

[Any follow-up actions needed]

2. 对话摘要：

在对话中提供简洁的摘要：

• 问题总数：X
• 已修复：Y
• 未解决：Z
• 隐患：[列出任何可能引入漏洞的风险]

---

漏洞检测

分析提交中的安全反模式。重点关注以下模式：

• 弱化访问控制（移除修饰符）
• 移除验证（删除 require/assert）
• 减少错误处理（移除 try/catch）
• 调整外部调用顺序（调用后才更新状态）
• 更改整数运算（移除 SafeMath）
• 弱化密码学机制

全面的检测模式和示例请参阅 references/bug-detection.md。

---

与其他技能的集成

differential-review： 用于对更改进行初步安全审查（审计前）

issue-writer： 用于将问题整理为正式审计报告

audit-context-building： 用于分析复杂修复时深入了解背景

---

有效审查的提示

建议：

• 验证实际的代码更改，而不只是查看提交消息
• 检查修复是否解决了根本原因，而不只是表面症状
• 留意相邻代码中意料之外的副作用
• 交叉核对可能相互影响的多个问题
• 为每项状态判定记录证据

避免：

• 将提交消息当作修复证据
• 因问题看似轻微而跳过
• 假定测试通过就代表修复正确
• 忽略“修复”范围之外的更改
• 在缺乏明确证据时标记为 FIXED

---

参考文件

如需详细指导，请参阅：

• references/finding-matching.md - 将提交与问题匹配的策略
• references/bug-detection.md - 全面的反模式检测
• references/report-parsing.md - 解析不同报告格式及 Google Drive 回退方案