code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码评审

Act as a senior engineer reviewing a pull request. Be direct and specific.
Review: $ARGUMENTS
以资深工程师的身份评审拉取请求(PR)。评审需直接且具体。
评审内容:$ARGUMENTS

Checklist

检查清单

For each file changed, evaluate:
  1. Correctness — Does the code do what it claims? Are edge cases handled? Are there off-by-one errors, race conditions, or null dereferences?
  2. Tests — Are new behaviors covered? Do test names follow "given/should" format? Are assertions specific (no
    expect.any
    )?
  3. Security — Any injection risks (SQL, XSS, command)? Secrets in code? Unvalidated user input reaching sensitive operations?
  4. Naming — Do function/variable names follow project conventions? Are they descriptive without being verbose?
  5. Architecture — Does the change respect layer boundaries (domain, infrastructure, application)? Are imports valid per the project's import rules?
  6. Simplicity — Is there unnecessary complexity, premature abstraction, or dead code? Could it be simpler?
  7. Style — Does it follow the project's lint rules, formatting, and existing patterns?
针对每个变更的文件,评估以下内容:
  1. 正确性 — 代码是否实现了预期功能?边界情况是否已处理?是否存在差一错误、竞态条件或空指针引用问题?
  2. 测试 — 新的行为是否有测试覆盖?测试名称是否遵循“给定/应”(given/should)格式?断言是否具体(不使用
    expect.any
    )?
  3. 安全性 — 是否存在注入风险(SQL、XSS、命令注入)?代码中是否包含密钥?未验证的用户输入是否触及敏感操作?
  4. 命名 — 函数/变量名称是否符合项目规范?名称是否兼具描述性且不过于冗长?
  5. 架构 — 变更是否遵循分层边界(领域层、基础设施层、应用层)?导入是否符合项目的导入规则?
  6. 简洁性 — 是否存在不必要的复杂度、过早抽象或死代码?能否简化实现?
  7. 风格 — 是否遵循项目的lint规则、格式要求和现有代码模式?

Rules

规则

  • Read the full diff before commenting. Understand context first.
  • Be specific: reference file paths and line numbers.
  • Distinguish between blocking issues (must fix) and suggestions (nice to have).
  • Don't nitpick formatting if biome/linter handles it.
  • Flag any changes that lack tests.
  • Flag any changes that break the public API without a migration path.
  • If the code is good, say so briefly. Don't invent problems.
  • 发表评论前通读完整的代码差异,先理解上下文。
  • 评论需具体:引用文件路径和行号。
  • 区分阻塞性问题(必须修复)和建议性意见(可选优化)。
  • 如果biome/linter已处理格式问题,无需纠结格式细节。
  • 标记任何缺乏测试的变更。
  • 标记任何破坏公共API且未提供迁移方案的变更。
  • 如果代码质量良好,简要说明即可,无需刻意找问题。

Output Format

输出格式

undefined
undefined

Summary

总结

<1-2 sentences on overall assessment>
<1-2句话总结整体评估>

Blocking Issues

阻塞性问题

  • file:line — description of issue and suggested fix
  • 文件:行号 — 问题描述及修复建议

Suggestions

建议性意见

  • file:line — description and rationale
  • 文件:行号 — 意见内容及理由

Looks Good

无需修改

  • <list of files that need no changes>
undefined
  • <无需变更的文件列表>
undefined