Back to Details

pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Reviewer

PR评审器

Execute a comprehensive PR review covering all four review perspectives from Freenet quality standards.
按照Freenet质量标准，执行涵盖全部四个评审视角的全面PR评审。

When to Use

使用时机

Use 
/freenet:pr-review <PR-NUMBER>
after a PR is ready for review, before merging.
当PR准备好进入评审环节、尚未合并时，使用
/freenet:pr-review <PR-NUMBER>
命令。

Review Process

评审流程

Step 1: Gather PR Context

步骤1：收集PR上下文

bash
undefined
bash
undefined

Get PR details

获取PR详情

gh pr view <NUMBER>
gh pr view <NUMBER>

Get the diff

获取差异内容

gh pr diff <NUMBER>
gh pr diff <NUMBER>

Check for linked issues

检查关联的Issue

Look for "Fixes #XXX" or "Closes #XXX" in description

查看描述中是否有“Fixes #XXX”或“Closes #XXX”的字样

gh issue view <ISSUE_NUMBER> # if linked
gh issue view <ISSUE_NUMBER> # 若有关联

List affected files

列出受影响的文件

gh pr diff <NUMBER> --name-only
gh pr diff <NUMBER> --name-only

Check CI status

检查CI状态

gh pr checks <NUMBER>
undefined
gh pr checks <NUMBER>
undefined

Step 2: Code-First Review

步骤2：代码优先评审

Review the code before reading the PR description to form an independent understanding.
Process:
  1. Read the diff without looking at the description
  2. Answer: What does this code do? What problem does it solve?
  3. Now read the PR description
  4. Compare your understanding with stated intent
  5. Flag any gaps or mismatches
Look for:
  • Does the code do what I think it should?
  • Are there hidden side effects?
  • Is the implementation approach sound?
在阅读PR描述之前先评审代码，形成独立的理解。
流程：
  1. 不看描述直接阅读差异内容
  2. 回答：这段代码的作用是什么？解决了什么问题？
  3. 现在阅读PR描述
  4. 将你的理解与声明的意图进行对比
  5. 标记任何差异或不匹配之处
检查要点：
  • 代码是否实现了我预期的功能？
  • 是否存在隐藏的副作用？
  • 实现方案是否合理？

Step 3: Testing Review

步骤3：测试评审

Analyze test coverage at all levels.
Check for:
  • Unit tests for new/modified functions
  • Integration tests for component interactions
  • Simulation tests for distributed behavior (if applicable)
  • E2E tests for user-facing changes
Questions to answer:
  • Does the regression test fail without the fix and pass with it?
  • Are edge cases covered?
  • Are error paths tested?
  • Would these tests catch similar bugs?
Red flags:
  • No tests for bug fixes
  • Tests that only check happy path
  • Removed or weakened test assertions
  • #[ignore]
    annotations
从各个层面分析测试覆盖率。
检查要点：
  • 新增/修改函数的单元测试
  • 组件交互的集成测试
  • 分布式行为的模拟测试（如适用）
  • 用户侧变更的端到端测试
需要回答的问题：
  • 没有该修复时回归测试是否失败，修复后是否通过？
  • 是否覆盖了边缘场景？
  • 错误路径是否经过测试？
  • 这些测试能否发现类似的Bug？
危险信号：
  • Bug修复没有对应的测试
  • 测试仅覆盖了正常流程
  • 移除或弱化了测试断言
  • 存在
    #[ignore]
    注解

Step 4: Skeptical Review

步骤4：批判性评审

Adversarial review looking for bugs, race conditions, and edge cases.
Attack vectors to explore:
  • Race conditions in concurrent code
  • Integer overflow/underflow
  • Null/None handling
  • Resource leaks (memory, file handles, connections)
  • Error propagation gaps
  • State machine invalid transitions
  • Timeout and retry edge cases
For each change, ask:
  • What happens if this fails?
  • What happens under high load?
  • What happens with malicious input?
  • What happens if called twice?
  • What happens if called out of order?
以对抗性的视角评审，寻找Bug、竞态条件和边缘场景。
需要排查的风险点：
  • 并发代码中的竞态条件
  • 整数溢出/下溢
  • Null/None处理
  • 资源泄漏（内存、文件句柄、连接）
  • 错误传播漏洞
  • 状态机无效转换
  • 超时与重试的边缘场景
针对每一处变更，思考：
  • 如果这部分失败会发生什么？
  • 高负载下会出现什么情况？
  • 遇到恶意输入会怎样？
  • 调用两次会有什么结果？
  • 乱序调用会发生什么？

Step 5: Big Picture Review

步骤5：全局视角评审

Ensure the PR actually solves the stated problem and doesn't exhibit "CI chasing" anti-patterns.
Check for removed code:
bash
undefined
确保PR确实解决了声明的问题，没有出现“为通过CI而妥协”的反模式。
检查被移除的代码：
bash
undefined

Look for deleted tests or fix code

查找被删除的测试或修复代码

gh pr diff <NUMBER> | grep -E '^-.*#[test]|^-.*fn test_|^-.*assert'

**Anti-patterns to detect:**
| Anti-Pattern | What to Look For |
|--------------|------------------|
| Ignored tests | `#[ignore]`, `skip`, `@Ignore` |
| Weakened assertions | Looser tolerances, `.ok()` on Results |
| Commented code | Especially tests or validation |
| Magic numbers | Hardcoded values replacing logic |
| Error swallowing | `.unwrap_or_default()`, silent fallbacks |

**Big picture questions:**
1. Does this PR actually solve the stated problem?
2. Does it fully address the linked issue?
3. Does it conflict with other open PRs?
4. Does it introduce patterns that will cause future problems?
5. Is there scope creep?
gh pr diff <NUMBER> | grep -E '^-.*#[test]|^-.*fn test_|^-.*assert'

**需要识别的反模式：**
| 反模式 | 检查要点 |
|--------------|------------------|
| 忽略测试 | `#[ignore]`, `skip`, `@Ignore` |
| 弱化断言 | 放宽的容差、对Result使用`.ok()` |
| 注释代码 | 尤其是测试或验证代码 |
| 魔法值 | 替代逻辑的硬编码值 |
| 错误吞噬 | `.unwrap_or_default()`、静默降级 |

**全局视角问题：**
1. 这个PR是否真正解决了声明的问题？
2. 是否完全解决了关联的Issue？
3. 是否与其他未合并的PR冲突？
4. 是否引入了会导致未来问题的模式？
5. 是否存在范围蔓延？

Step 6: Documentation Review

步骤6：文档评审

Check if documentation is complete:
  • Code docs: Do new public items have doc comments?
  • Architecture docs: Do changes require doc updates?
  • User docs: Are CLI/config changes documented?
  • Stale docs: Do any existing docs contradict the changes?
检查文档是否完整：
  • **代码文档：**新增的公共项是否有文档注释？
  • **架构文档：**变更是否需要更新文档？
  • **用户文档：**CLI/配置变更是否有文档说明？
  • **过时文档：**现有文档是否与变更内容矛盾？

Output Format

输出格式

Produce a consolidated review report:
markdown
undefined
生成一份整合的评审报告：
markdown
undefined

Comprehensive PR Review: #<NUMBER>

全面PR评审报告：#<NUMBER>

Summary

摘要

  • PR Title: <title>
  • Type: <feat/fix/refactor/etc>
  • CI Status: <passing/failing/pending>
  • Linked Issues: <issue numbers or "none">
  • PR标题： <title>
  • 类型： <feat/fix/refactor/etc>
  • CI状态： <passing/failing/pending>
  • 关联Issue： <issue编号或“无”>

Code-First Analysis

代码优先分析

Independent Understanding: <what the code appears to do> Stated Intent: <from PR description> Alignment: <matches/partially matches/misaligned> Gaps: <any discrepancies>
独立理解： <代码的实际功能> 声明意图： <来自PR描述> 匹配度： <匹配/部分匹配/不匹配> 差异点： <任何不一致之处>

Testing Assessment

测试评估

Coverage Level: <adequate/insufficient/excessive>
Test TypeStatusNotes
Unit✅/❌/⚠️<details>
Integration✅/❌/⚠️<details>
Simulation✅/❌/N/A<details>
E2E✅/❌/N/A<details>
Regression Test: <present and valid / missing / insufficient> Missing Tests: <list specific gaps>
覆盖程度： <充足/不足/过度>
测试类型状态备注
单元测试✅/❌/⚠️<详情>
集成测试✅/❌/⚠️<详情>
模拟测试✅/❌/不适用<详情>
端到端测试✅/❌/不适用<详情>
回归测试： <存在且有效 / 缺失 / 不足> 缺失测试： <列出具体的漏洞>

Skeptical Findings

批判性评审发现

Risk Level: <low/medium/high>
ConcernSeverityLocationDetails
<issue><high/med/low>file:line<explanation>
风险等级： <低/中/高>
问题严重程度位置详情
<问题描述><高/中/低><文件:行号><解释>

Big Picture Assessment

全局视角评估

Goal Alignment: <yes/partial/no> Anti-Patterns Detected: <list or "none"> Removed Code Concerns: <list or "none"> Scope Assessment: <focused/some creep/significant creep>
目标匹配度： <是/部分/否> 检测到的反模式： <列出或“无”> 代码移除相关问题： <列出或“无”> 范围评估： <聚焦/轻微蔓延/严重蔓延>

Documentation

文档情况

  • Code docs: <complete/incomplete/missing>
  • Architecture docs: <up-to-date/needs-update/n/a>
  • User docs: <up-to-date/needs-update/n/a>
  • 代码文档：<完整/不完整/缺失>
  • 架构文档：<最新/需要更新/不适用>
  • 用户文档：<最新/需要更新/不适用>

Recommendations

建议

Must Fix (Blocking)

必须修复（阻塞合并）

  1. <critical issues that must be addressed>
  1. <必须解决的关键问题>

Should Fix (Important)

应该修复（重要）

  1. <significant issues that should be addressed>
  1. <需要解决的重大问题>

Consider (Suggestions)

建议优化（可选）

  1. <minor improvements or style suggestions>
  1. <次要改进或风格建议>

Verdict

评审结论

Ready to Merge: <Yes / No - needs changes / No - needs discussion>
<If not ready, summarize what's needed>
undefined
是否可合并： <是 / 否-需修改 / 否-需讨论>
<若不可合并，总结所需的修改内容>
undefined

Parallel Subagent Reviews

并行子Agent评审

For deeper analysis, spawn the specialized review agents in parallel using the Task tool with 
subagent_type="general-purpose"
. Include the agent definition (from 
agents/
) in each prompt so the subagent follows the correct review methodology.
Spawn all four in parallel using Task tool (all use subagent_type="general-purpose"):

1. "You are a code-first-reviewer. [Include agents/code-first-reviewer.md instructions]
    Review PR #<NUMBER> in freenet/freenet-core"

2. "You are a testing-reviewer. [Include agents/testing-reviewer.md instructions]
    Review test coverage for PR #<NUMBER> in freenet/freenet-core"

3. "You are a skeptical-reviewer. [Include agents/skeptical-reviewer.md instructions]
    Do a skeptical review of PR #<NUMBER> in freenet/freenet-core"

4. "You are a big-picture-reviewer. [Include agents/big-picture-reviewer.md instructions]
    Do a big-picture review of PR #<NUMBER> in freenet/freenet-core"
如需更深入的分析，使用Task工具并行启动专业评审Agent，设置
subagent_type="general-purpose"
。在每个提示中包含Agent定义（来自
agents/
目录），确保子Agent遵循正确的评审方法。
使用Task工具并行启动所有四个Agent（均设置subagent_type="general-purpose"）：

1. "你是一名代码优先评审员。[包含agents/code-first-reviewer.md中的指导说明] 评审freenet/freenet-core仓库中的PR #<NUMBER>"

2. "你是一名测试评审员。[包含agents/testing-reviewer.md中的指导说明] 评审freenet/freenet-core仓库中PR #<NUMBER>的测试覆盖率"

3. "你是一名批判性评审员。[包含agents/skeptical-reviewer.md中的指导说明] 对freenet/freenet-core仓库中的PR #<NUMBER>进行批判性评审"

4. "你是一名全局视角评审员。[包含agents/big-picture-reviewer.md中的指导说明] 对freenet/freenet-core仓库中的PR #<NUMBER>进行全局视角评审"

Quality Standards

质量标准

  • Be thorough but constructive
  • Cite specific files and line numbers
  • Explain WHY something is a problem, not just WHAT
  • Suggest fixes, not just criticisms
  • Acknowledge what's done well
  • Don't nitpick style if it matches codebase conventions
  • 全面且具有建设性
  • 引用具体的文件和行号
  • 解释问题的原因，而非仅指出问题本身
  • 提出修复建议，而非仅批评
  • 认可做得好的地方
  • 如果符合代码库规范，不要在风格上吹毛求疵