Back to Details

pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Review

PR代码审查

Diff-based code review across five dimensions. Reads the changed files, selects applicable review methodologies, and produces an aggregated report with severity-ranked findings.
基于diff的五大维度代码审查。读取变更文件，选择适用的审查方法，生成汇总报告，包含按严重程度排序的审查结果。

Reference Files

参考文件

FileContentsLoad When
references/code-review.md
Guideline compliance, bug detection, confidence scoringAlways
references/test-analysis.md
Behavioral test coverage, criticality ratingTest files changed
references/error-handling.md
Silent failure patterns, catch block analysisError handling changed
references/type-design.md
Invariant analysis, 4-dimension rating rubricType definitions added/modified
references/comment-quality.md
Comment accuracy, long-term value, rot detectionComments/docstrings added
文件内容加载条件
references/code-review.md
规范合规性、漏洞检测、置信度评分始终加载
references/test-analysis.md
行为测试覆盖率、严重程度评级测试文件变更时
references/error-handling.md
静默故障模式、catch块分析错误处理逻辑变更时
references/type-design.md
不变量分析、4维评级标准新增/修改类型定义时
references/comment-quality.md
注释准确性、长期价值、过时检测新增注释/文档字符串时

Workflow

工作流

Phase 1: Scope

阶段1：范围确认

  1. Determine the review target:
    • Default: 
      git diff
      (unstaged changes)
    • If user specifies a PR: 
      git diff main...HEAD
      or 
      gh pr diff <number>
    • If user specifies files: review those files directly
  2. List all changed files with 
    git diff --name-only
  3. Read the project's CLAUDE.md (if present) for project-specific rules
  1. 确定审查目标：
    • 默认：
      git diff
      （未暂存变更）
    • 若用户指定PR：
      git diff main...HEAD
      或 
      gh pr diff <number>
    • 若用户指定文件：直接审查这些文件
  2. 用
    git diff --name-only
    列出所有变更文件
  3. 读取项目的CLAUDE.md（如果存在）获取项目专属规则

Phase 2: Route

阶段2：维度匹配

Classify changed files and select applicable dimensions:
ConditionDimensionReference to Load
AlwaysCode review
references/code-review.md
Files matching 
*test*
, 
*spec*
, 
*_test.*
, 
test_*
Test analysis
references/test-analysis.md
Files containing try/catch, except, .catch, Result, error callbacksError handling
references/error-handling.md
Files containing class, interface, type, struct, enum, dataclass definitionsType design
references/type-design.md
Files with new/modified docstrings, JSDoc, or block commentsComment quality
references/comment-quality.md
Load only the reference files that apply. Skip dimensions with no matching files.
对变更文件分类，选择适用的审查维度：
条件维度加载的参考文件
始终满足代码审查
references/code-review.md
文件匹配 
*test*
、
*spec*
、
*_test.*
、
test_*
测试分析
references/test-analysis.md
文件包含try/catch、except、.catch、Result、错误回调错误处理
references/error-handling.md
文件包含class、interface、type、struct、enum、dataclass定义类型设计
references/type-design.md
文件有新增/修改的文档字符串、JSDoc或块注释注释质量
references/comment-quality.md
仅加载适用的参考文件，跳过无匹配文件的维度。

Phase 3: Review

阶段3：执行审查

For each applicable dimension, analyze the diff using the loaded methodology:
  1. Code review — scan every changed file for guideline violations and bugs. Apply confidence scoring (0-100). Only report issues >= 80.
  2. Test analysis — map test coverage to changed code paths. Rate gaps 1-10. Only report gaps >= 5.
  3. Error handling — examine every error handler in the diff for silent failures. Classify CRITICAL/HIGH/MEDIUM.
  4. Type design — evaluate new or modified types on 4 dimensions (encapsulation, invariant expression, usefulness, enforcement). Rate each 1-10.
  5. Comment quality — verify accuracy, assess long-term value, flag comment rot.
针对每个适用维度，使用加载的方法论分析diff：
  1. 代码审查 — 扫描所有变更文件是否存在规范违反和漏洞。应用置信度评分（0-100），仅报告得分>=80的问题。
  2. 测试分析 — 将测试覆盖率映射到变更的代码路径，对覆盖率缺口按1-10评级，仅报告得分>=5的缺口。
  3. 错误处理 — 检查diff中所有错误处理逻辑是否存在静默故障，按CRITICAL/HIGH/MEDIUM分类。
  4. 类型设计 — 从4个维度评估新增或修改的类型（封装性、不变量表达、实用性、强制约束），每个维度按1-10评级。
  5. 注释质量 — 验证准确性、评估长期价值、标记过时注释。

Phase 4: Aggregate

阶段4：结果汇总

Merge all findings into a single report, deduplicated and severity-ranked.
Deduplication rules:
  • If two dimensions flag the same file:line, keep the higher-severity finding
  • If code-review and error-handling both flag an empty catch block, merge into one finding with the error-handling severity (it's the specialist)
Severity mapping across dimensions:
DimensionMaps to CriticalMaps to ImportantMaps to Suggestion
Code reviewConfidence 90-100Confidence 80-89—
Test analysisRating 9-10Rating 7-8Rating 5-6
Error handlingCRITICALHIGHMEDIUM
Type designAny rating <= 3/10Any rating 4-6/10Rating 7-8/10
Comment qualityFactually incorrectMisleading or incompleteRestates obvious code
将所有审查结果合并为单个报告，去重后按严重程度排序。
去重规则：
  • 若两个维度标记了同一个文件的同一行，保留严重程度更高的结果
  • 若代码审查和错误处理都标记了空catch块，合并为一条结果，采用错误处理维度的严重程度（该维度更专业）
跨维度严重程度映射：
维度对应严重级别Critical对应严重级别Important对应严重级别Suggestion
代码审查置信度90-100置信度80-89—
测试分析评级9-10评级7-8评级5-6
错误处理CRITICALHIGHMEDIUM
类型设计任意评级<=3/10任意评级4-6/10评级7-8/10
注释质量事实错误误导性或不完整重复说明显而易见的代码

Output Format

输出格式

undefined
undefined

PR Review Summary

PR Review Summary

Scope: [X files changed, Y dimensions applied] Dimensions: [list of active dimensions]
Scope: [X files changed, Y dimensions applied] Dimensions: [list of active dimensions]

Critical Issues (must fix before merge)

Critical Issues (must fix before merge)

  • [dimension] 
    file:line
    — Description. Fix suggestion.
  • [dimension] 
    file:line
    — Description. Fix suggestion.

Important Issues (should fix)

Important Issues (should fix)

  • [dimension] 
    file:line
    — Description. Fix suggestion.
  • [dimension] 
    file:line
    — Description. Fix suggestion.

Suggestions (consider)

Suggestions (consider)

  • [dimension] 
    file:line
    — Description.
  • [dimension] 
    file:line
    — Description.

Strengths

Strengths

  • What's well-done in this changeset.
  • What's well-done in this changeset.

Recommended Action

Recommended Action

  1. Fix critical issues
  2. Address important issues
  3. Consider suggestions
  4. Re-run review after fixes

If no issues are found at any severity level, confirm the code meets standards with
a brief summary of what was reviewed and which dimensions were applied.

---
  1. Fix critical issues
  2. Address important issues
  3. Consider suggestions
  4. Re-run review after fixes

如果所有严重级别都未发现问题，确认代码符合标准，简要说明审查内容和应用的维度即可。

---

Aspect Selection

维度选择

Users can request specific dimensions instead of running all:
User SaysDimensions Applied
"review my PR" / "check my changes"All applicable (default)
"review the code" / "check code quality"Code review only
"check the tests" / "is test coverage good"Test analysis only
"check error handling" / "find silent failures"Error handling only
"review the types" / "check type design"Type design only
"check the comments" / "review documentation"Comment quality only
When a specific aspect is requested, load only that reference file and skip routing.
用户可以指定特定审查维度，无需运行所有维度：
用户指令应用的维度
"review my PR" / "check my changes"所有适用维度（默认）
"review the code" / "check code quality"仅代码审查
"check the tests" / "is test coverage good"仅测试分析
"check error handling" / "find silent failures"仅错误处理
"review the types" / "check type design"仅类型设计
"check the comments" / "review documentation"仅注释质量
当用户指定特定维度时，仅加载对应的参考文件，跳过维度匹配步骤。

Error Handling

错误处理

ProblemResolution
No git diff availableAsk user to specify files or scope
CLAUDE.md not foundReview against general best practices; note the absence
No test files in diffSkip test analysis dimension; note in output
Diff is emptyReport "no changes to review" and stop
Diff exceeds context limitsFocus on files the user is most likely to care about; summarize skipped files
问题解决方案
无可用git diff要求用户指定文件或审查范围
未找到CLAUDE.md按照通用最佳实践审查，并注明未找到项目专属规则
diff中无测试文件跳过测试分析维度，并在输出中注明
diff为空报告"no changes to review"并终止流程
diff超出上下文限制重点审查用户最关心的文件，汇总说明跳过的文件

Calibration Rules

校准规则

  1. Precision over recall. A false positive erodes trust in the review. Only report issues at >= 80 confidence (code review) or >= 5 criticality (tests). Silence is better than noise.
  2. File:line references are mandatory. Every finding must include a specific location. Vague findings ("consider improving error handling") are not actionable.
  3. Project rules override general rules. If CLAUDE.md says "use arrow functions", do not flag arrow functions even if conventional style prefers 
    function
    declarations.
  4. Deduplication is mandatory. If two dimensions flag the same issue, merge them. Never report the same problem twice.
  5. Acknowledge strengths. A review that only lists problems is demoralizing. Note what's done well, even briefly.
  6. Code-refiner handles simplification. This skill reviews and reports. It does not refactor or simplify — that's the 
    code-refiner
    skill's job. Keep the roles separate.
  1. 精准优先于全面。误报会侵蚀对审查结果的信任。仅报告置信度>=80（代码审查）或严重程度>=5（测试）的问题，无结果好过噪声结果。
  2. 必须包含文件:行号引用。每条结果都必须包含具体位置，模糊的结果（如"考虑优化错误处理"）不具备可执行性。
  3. 项目规则优先于通用规则。如果CLAUDE.md中规定"使用箭头函数"，即使通用规范更偏好
    function
    声明，也不要标记箭头函数为问题。
  4. 必须去重。如果两个维度标记了同一个问题，合并处理，禁止重复报告同一个问题。
  5. 肯定优点。仅列出问题的审查会打击积极性，即使很简短也要注明做得好的地方。
  6. 代码优化由code-refiner负责。本skill仅负责审查和报告，不负责重构或简化代码——那是
    code-refiner
    skill的职责，保持角色分离。