Back to Details

fix-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix Review

修复审查

Differential analysis to verify commits address security findings without introducing bugs.
通过差异分析验证提交是否解决了安全问题且未引入Bug。

When to Use

适用场景

  • Reviewing fix branches against security audit reports
  • Validating that remediation commits actually address findings
  • Checking if specific findings (TOB-XXX format) have been fixed
  • Analyzing commit ranges for bug introduction patterns
  • Cross-referencing code changes with audit recommendations
  • 对照安全审计报告审查修复分支
  • 验证整改提交是否真正解决了发现的问题
  • 检查特定问题（TOB-XXX格式）是否已修复
  • 分析提交范围中的Bug引入模式
  • 交叉比对代码变更与审计建议

When NOT to Use

不适用场景

  • Initial security audits (use audit-context-building or differential-review)
  • Code review without a specific baseline or finding set
  • Greenfield development with no prior audit
  • Documentation-only changes
  • 初始安全审计（使用审计上下文构建或差异审查技能）
  • 无特定基线或问题集合的代码审查
  • 无前置审计的全新开发项目
  • 仅涉及文档变更的情况

Rationalizations (Do Not Skip)

常见误区（不可忽略）

RationalizationWhy It's WrongRequired Action
"The commit message says it fixes TOB-XXX"Messages lie; code tells truthVerify the actual code change addresses the finding
"Small fix, no new bugs possible"Small changes cause big bugsAnalyze all changes for anti-patterns
"I'll check the important findings"All findings matterSystematically check every finding
"The tests pass"Tests may not cover the fixVerify fix logic, not just test status
"Same developer, they know the code"Familiarity breeds blind spotsFresh analysis of every change
合理化借口错误原因必要操作
“提交信息说已修复TOB-XXX”提交信息可能不实，代码才是真相验证实际代码变更是否解决了问题
“修复很小，不可能引入新Bug”小变更也可能引发大问题分析所有变更是否存在反模式
“我只检查重要的问题”所有问题都至关重要系统性检查每一个问题
“测试通过了”测试可能未覆盖修复内容验证修复逻辑，而非仅看测试状态
“同一个开发者，他们熟悉代码”熟悉会导致盲区对每一处变更进行全新分析

Quick Reference

快速参考

Input Requirements

输入要求

InputRequiredFormat
Source commitYesGit commit hash or ref (baseline before fixes)
Target commit(s)YesOne or more commit hashes to analyze
Security reportNoLocal path, URL, or Google Drive link
输入项是否必填格式
源提交是Git提交哈希或引用（修复前的基线）
目标提交是一个或多个待分析的提交哈希
安全报告否本地路径、URL或Google Drive链接

Finding Status Values

问题状态值

StatusMeaning
FIXEDCode change directly addresses the finding
PARTIALLY_FIXEDSome aspects addressed, others remain
NOT_ADDRESSEDNo relevant changes found
CANNOT_DETERMINEInsufficient context to verify
状态含义
FIXED代码变更直接解决了问题
PARTIALLY_FIXED部分问题已解决，其余仍存在
NOT_ADDRESSED未发现相关变更
CANNOT_DETERMINE上下文不足，无法验证

Workflow

工作流程

Phase 1: Input Gathering

阶段1：收集输入

Collect required inputs from user:
Source commit:  [hash/ref before fixes]
Target commit:  [hash/ref to analyze]
Report:         [optional: path, URL, or "none"]
If user provides multiple target commits, process each separately with the same source.
向用户收集所需输入：
源提交:  [修复前的哈希/引用]
目标提交:  [待分析的哈希/引用]
报告:         [可选：路径、URL或“无”]
若用户提供多个目标提交，使用同一个源提交分别处理每个目标提交。

Phase 2: Report Retrieval

阶段2：获取报告

When a security report is provided, retrieve it based on format:
Local file (PDF, MD, JSON, HTML): Read the file directly using the Read tool. Claude processes PDFs natively.
URL: Fetch web content using the WebFetch tool.
Google Drive URL that fails: See 
references/report-parsing.md
for Google Drive fallback logic using 
gdrive
CLI.
当提供安全报告时，根据格式获取报告内容：
本地文件（PDF、MD、JSON、HTML）： 使用Read工具直接读取文件。Claude可原生处理PDF文件。
URL： 使用WebFetch工具获取网页内容。
无法访问的Google Drive URL： 查看
references/report-parsing.md
，了解使用
gdrive
CLI的Google Drive备用逻辑。

Phase 3: Finding Extraction

阶段3：提取问题

Parse the report to extract findings:
Trail of Bits format:
  • Look for "Detailed Findings" section
  • Extract findings matching pattern: 
    TOB-[A-Z]+-[0-9]+
  • Capture: ID, title, severity, description, affected files
Other formats:
  • Numbered findings (Finding 1, Finding 2)
  • Severity-based sections (Critical, High, Medium, Low)
  • JSON with 
    findings
    array
See 
references/report-parsing.md
for detailed parsing strategies.
解析报告以提取问题：
Trail of Bits格式：
  • 查找“详细问题”章节
  • 提取符合
    TOB-[A-Z]+-[0-9]+
    格式的问题
  • 捕获：ID、标题、严重程度、描述、受影响文件
其他格式：
  • 编号问题（问题1、问题2）
  • 按严重程度划分的章节（关键、高、中、低）
  • 包含
    findings
    数组的JSON格式
查看
references/report-parsing.md
获取详细解析策略。

Phase 4: Commit Analysis

阶段4：提交分析

For each target commit, analyze the commit range:
bash
undefined
对每个目标提交，分析提交范围：
bash
undefined

Get commit list from source to target

获取从源到目标的提交列表

git log <source>..<target> --oneline
git log <source>..<target> --oneline

Get full diff

获取完整差异

git diff <source>..<target>
git diff <source>..<target>

Get changed files

获取变更的文件

git diff <source>..<target> --name-only

For each commit in the range:
1. Examine the diff for bug introduction patterns
2. Check for security anti-patterns (see `references/bug-detection.md`)
3. Map changes to relevant findings
git diff <source>..<target> --name-only

对范围内的每个提交：
1. 检查差异中是否存在Bug引入模式
2. 检查是否存在安全反模式（查看`references/bug-detection.md`）
3. 将变更映射到相关问题

Phase 5: Finding Verification

阶段5：问题验证

For each finding in the report:
  1. Identify relevant commits - Match by:
    • File paths mentioned in finding
    • Function/variable names in finding description
    • Commit messages referencing the finding ID
  2. Verify the fix - Check that:
    • The root cause is addressed (not just symptoms)
    • The fix follows the report's recommendation
    • No new vulnerabilities are introduced
  3. Assign status - Based on evidence:
    • FIXED: Clear code change addresses the finding
    • PARTIALLY_FIXED: Some aspects fixed, others remain
    • NOT_ADDRESSED: No relevant changes
    • CANNOT_DETERMINE: Need more context
  4. Document evidence - For each finding:
    • Commit hash(es) that address it
    • Specific file and line changes
    • How the fix addresses the root cause
See 
references/finding-matching.md
for detailed matching strategies.
对报告中的每个问题：
  1. 识别相关提交 - 通过以下方式匹配：
    • 问题中提及的文件路径
    • 问题描述中的函数/变量名
    • 引用问题ID的提交信息
  2. 验证修复 - 检查：
    • 是否解决了根本原因（而非仅表面症状）
    • 修复是否遵循报告中的建议
    • 未引入新的漏洞
  3. 分配状态 - 根据证据：
    • FIXED：明确的代码变更解决了问题
    • PARTIALLY_FIXED：部分问题已解决，其余仍存在
    • NOT_ADDRESSED：无相关变更
    • CANNOT_DETERMINE：需要更多上下文
  4. 记录证据 - 为每个问题记录：
    • 解决问题的提交哈希
    • 具体的文件和行变更
    • 修复如何解决根本原因
查看
references/finding-matching.md
获取详细匹配策略。

Phase 6: Output Generation

阶段6：生成输出

Generate two outputs:
1. Report file (
FIX_REVIEW_REPORT.md
):
markdown
undefined
生成两类输出：
1. 报告文件（
FIX_REVIEW_REPORT.md
）：
markdown
undefined

Fix Review Report

修复审查报告

Source: <commit> Target: <commit> Report: <path or "none"> Date: <date>
源提交: <提交哈希> 目标提交: <提交哈希> 报告: <路径或“无”> 日期: <日期>

Executive Summary

执行摘要

[Brief overview: X findings reviewed, Y fixed, Z concerns]
[简要概述：共审查X个问题，Y个已修复，Z个关注点]

Finding Status

问题状态

IDTitleSeverityStatusEvidence
TOB-XXX-1Finding titleHighFIXEDabc123
TOB-XXX-2Another findingMediumNOT_ADDRESSED-
ID标题严重程度状态证据
TOB-XXX-1问题标题高FIXEDabc123
TOB-XXX-2另一个问题中NOT_ADDRESSED-

Bug Introduction Concerns

Bug引入风险

[Any potential bugs or regressions detected in the changes]
[变更中检测到的潜在Bug或回归问题]

Per-Commit Analysis

逐提交分析

Commit abc123: "Fix reentrancy in withdraw()"

提交abc123: "修复withdraw()中的重入问题"

Files changed: contracts/Vault.sol Findings addressed: TOB-XXX-1 Concerns: None
[Detailed analysis]
变更文件: contracts/Vault.sol 解决的问题: TOB-XXX-1 关注点: 无
[详细分析]

Recommendations

建议

[Any follow-up actions needed]

**2. Conversation summary:**

Provide a concise summary in the conversation:
- Total findings: X
- Fixed: Y
- Not addressed: Z
- Concerns: [list any bug introduction risks]

---
[所需的后续行动]

**2. 对话摘要:**

在对话中提供简洁摘要：
- 总问题数：X
- 已修复：Y
- 未解决：Z
- 关注点：[列出所有Bug引入风险]

---

Bug Detection

Bug检测

Analyze commits for security anti-patterns. Key patterns to watch:
  • Access control weakening (modifiers removed)
  • Validation removal (require/assert deleted)
  • Error handling reduction (try/catch removed)
  • External call reordering (state after call)
  • Integer operation changes (SafeMath removed)
  • Cryptographic weakening
See 
references/bug-detection.md
for comprehensive detection patterns and examples.
分析提交中的安全反模式。需重点关注的模式：
  • 访问控制弱化（移除修饰器）
  • 验证逻辑移除（删除require/assert）
  • 错误处理减少（移除try/catch）
  • 外部调用重排序（调用后修改状态）
  • 整数运算变更（移除SafeMath）
  • 加密逻辑弱化
查看
references/bug-detection.md
获取全面的检测模式及示例。

Integration with Other Skills

与其他技能的集成

differential-review: For initial security review of changes (before audit)
issue-writer: To format findings into formal audit reports
audit-context-building: For deep context when analyzing complex fixes
differential-review: 用于变更的初始安全审查（审计前）
issue-writer: 将问题格式化为正式审计报告
audit-context-building: 分析复杂修复时获取深层上下文

Tips for Effective Reviews

高效审查技巧

Do:
  • Verify the actual code change, not just commit messages
  • Check that fixes address root causes, not symptoms
  • Look for unintended side effects in adjacent code
  • Cross-reference multiple findings that may interact
  • Document evidence for every status assignment
Don't:
  • Trust commit messages as proof of fix
  • Skip findings because they seem minor
  • Assume passing tests mean correct fixes
  • Ignore changes outside the "fix" scope
  • Mark FIXED without clear evidence
应做：
  • 验证实际代码变更，而非仅看提交信息
  • 确保修复解决了根本原因，而非表面症状
  • 检查相邻代码中是否存在意外副作用
  • 交叉引用可能相互影响的多个问题
  • 为每个状态分配记录证据
不应做：
  • 将提交信息视为修复的证明
  • 因问题看似微小而忽略
  • 假设测试通过就代表修复正确
  • 忽略“修复”范围外的变更
  • 无明确证据时标记为FIXED

Reference Files

参考文件

For detailed guidance, consult:
  • references/finding-matching.md
     - Strategies for matching commits to findings
  • references/bug-detection.md
     - Comprehensive anti-pattern detection
  • references/report-parsing.md
     - Parsing different report formats, Google Drive fallback
如需详细指导，请查阅：
  • references/finding-matching.md
     - 提交与问题的匹配策略
  • references/bug-detection.md
     - 全面的反模式检测指南
  • references/report-parsing.md
     - 不同报告格式的解析方法及Google Drive备用方案