review-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Review

PR审查

Perform systematic review with actionable, validated feedback only.
执行系统性审查,仅提供可执行、经过验证的反馈。

Scope

范围

  • Use for PR review, branch or diff review, and pre-merge checks
  • Skip closed or already-reviewed PRs, draft PRs unless explicitly requested, and trivial bot-only updates
  • 适用于PR审查、分支或差异审查,以及预合并检查
  • 跳过已关闭或已审查的PR、草稿PR(除非明确要求),以及仅由机器人进行的微小更新

Workflow

工作流程

  1. Validate target:
    • Confirm repo, base or head, and requested review scope
    • Skip and explain briefly when the target is out of scope
  2. Gather context:
    • Capture PR intent, changed files, and relevant CLAUDE.md files
    • Apply only in-scope CLAUDE.md rules for the changed paths
  3. Choose review shape by size:
    • Small change: one pass covering bugs and CLAUDE.md compliance
    • Medium change: two parallel passes (bugs, CLAUDE.md)
    • Large change: shard by subsystem and run parallel passes per shard
  4. Validate issues:
    • Re-check exact lines before reporting
    • Keep only high-confidence issues; drop speculative or duplicate items
  5. Post:
    • Preferred: inline comments with reasoning
    • Fallback: same issue format in chat when inline tooling is unavailable
    • If no issues remain, post the no-issues summary
  1. 验证目标:
    • 确认仓库、基准或分支头,以及请求的审查范围
    • 若目标超出范围,直接跳过并简要说明
  2. 收集上下文:
    • 记录PR的意图、变更文件以及相关的CLAUDE.md文件
    • 仅对变更路径应用范围内的CLAUDE.md规则
  3. 根据规模选择审查方式:
    • 小型变更:单次检查,覆盖bug和CLAUDE.md合规性
    • 中型变更:并行进行两次检查(bug检查、CLAUDE.md合规性检查)
    • 大型变更:按子系统拆分,对每个拆分部分进行并行检查
  4. 验证问题:
    • 报告前重新检查具体代码行
    • 仅保留高可信度问题;剔除推测性或重复的问题
  5. 提交结果:
    • 首选方式:带有推理过程的内联评论
    • 备选方式:当内联工具不可用时,在聊天中使用相同的问题格式
    • 若无问题,提交无问题总结

High signal only

仅报告高信号问题

Flag only when certain:
  • Code will fail to compile (syntax, types, imports)
  • Code will produce incorrect behavior (clear logic or state errors)
  • Code introduces a concrete security risk with direct exploit path
  • Unambiguous CLAUDE.md violation (quote rule, verify scope)
Never flag:
  • Style, quality, or subjective preferences
  • Pre-existing issues unrelated to the change
  • Potential issues dependent on unknown inputs
  • Linter-only issues likely caught automatically
  • Explicitly silenced violations
仅在确定以下情况时标记问题:
  • 代码无法编译(语法、类型、导入错误)
  • 代码会产生错误行为(明确的逻辑或状态错误)
  • 代码引入了具有直接利用路径的具体安全风险
  • 明确违反CLAUDE.md规范(引用规则,验证范围)
绝不标记以下情况:
  • 风格、质量或主观偏好问题
  • 与本次变更无关的原有问题
  • 依赖未知输入的潜在问题
  • 可能已被自动检查工具捕获的仅属于代码规范检查器(Linter)的问题
  • 被明确忽略的违规情况

Output format

输出格式

Use
github_inline_comment:create_inline_comment
when available.
For each unique issue, use this structure:
markdown
[<severity>] <short factual title>

Why this is a bug or violation:
<one to three sentences with concrete impact>

Evidence:
- Rule or code reference
- Full-SHA link: https://github.com/owner/repo/blob/[40-char-sha]/path/to/file.ts#L10-L18

Suggested fix:
<committable patch snippet if <= 6 lines; otherwise clear implementation guidance>
When inline tooling is unavailable, return the same structure in chat and include
path:line
for each issue.
Summary (if no issues):
undefined
当可用时,使用
github_inline_comment:create_inline_comment
工具。
对于每个独特的问题,使用以下结构:
markdown
[<severity>] <short factual title>

Why this is a bug or violation:
<one to three sentences with concrete impact>

Evidence:
- Rule or code reference
- Full-SHA link: https://github.com/owner/repo/blob/[40-char-sha]/path/to/file.ts#L10-L18

Suggested fix:
<committable patch snippet if <= 6 lines; otherwise clear implementation guidance>
当内联工具不可用时,在聊天中返回相同结构,并为每个问题包含
path:line
信息。
总结 (若无问题):
undefined

Code review

Code review

No issues found. Checked for concrete bugs and CLAUDE.md compliance.
undefined
No issues found. Checked for concrete bugs and CLAUDE.md compliance.
undefined

Anti-patterns

反模式

  • "This might cause issues" -> "Variable
    x
    is undefined at
    src/foo.ts:45
    , causing
    ReferenceError
    at runtime."
  • "Consider refactoring" -> "Violates CLAUDE.md rule '<quoted rule>' in scoped file
    src/foo.ts
    ."
  • Multiple comments for the same root cause -> one comment linking all affected locations
Every flagged issue should be something a senior engineer would catch.
  • "This might cause issues" -> "Variable
    x
    is undefined at
    src/foo.ts:45
    , causing
    ReferenceError
    at runtime."
  • "Consider refactoring" -> "Violates CLAUDE.md rule '<quoted rule>' in scoped file
    src/foo.ts
    ."
  • Multiple comments for the same root cause -> one comment linking all affected locations
Every flagged issue should be something a senior engineer would catch.