Back to Details

cmd-pr-sweep

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review Sweep

代码审查巡检

Review all recent changes (staged, unstaged, or a specified branch diff) across five dimensions. Focus on actionable findings — skip nitpicks.
审查所有最近的变更（暂存、未暂存，或指定分支的差异），覆盖五个维度。聚焦可落地的发现，跳过吹毛求疵的细节。

Instructions

使用说明

  1. Identify the change scope — ask the user if unclear:
    • Uncommitted changes: 
      git diff HEAD
    • Branch diff: 
      git diff main...HEAD
    • Specific files: user-provided list
  2. Read all changed files in full before reviewing. Understand the existing patterns, not just the diff.
  3. Review each dimension below. For each finding, cite the file and line.
  1. 确定变更范围——如果范围不明确请询问用户：
    • 未提交变更：
      git diff HEAD
    • 分支差异：
      git diff main...HEAD
    • 指定文件：用户提供的列表
  2. 审查前完整阅读所有变更文件，理解代码库现有模式，而不仅仅是查看差异内容。
  3. 审查以下每个维度，每条发现都需要标注对应的文件和行号。

Review Dimensions

审查维度

1. Test Gaps

1. 测试缺口

  • Are there new code paths without corresponding tests?
  • Are edge cases covered (empty inputs, error paths, boundary values)?
  • Do existing tests still pass with the changes?
  • Are there testable utilities or helpers that lack unit tests?
  • 是否存在没有对应测试的新代码路径？
  • 边缘场景是否被覆盖（空输入、错误路径、边界值）？
  • 现有测试在代码变更后是否仍然可以正常通过？
  • 是否存在缺少单元测试的可测试工具函数或辅助方法？

2. Simplification

2. 简化度

  • Can any conditional branches be collapsed or removed?
  • Are there unnecessary abstractions (wrappers, factories, indirection) for single-use cases?
  • Can complex expressions be broken into named variables for clarity?
  • Are there redundant checks or defensive code that can't trigger?
  • 是否存在可以合并或删除的条件分支？
  • 是否存在仅单次使用的不必要抽象（包装器、工厂、间接层）？
  • 复杂表达式是否可以拆分为命名变量来提升可读性？
  • 是否存在永远不会触发的冗余检查或防御性代码？

3. Naming Consistency

3. 命名一致性

  • Do new names follow existing conventions in the codebase?
  • Are abbreviations used consistently (don't mix 
    repo
    /
    repository
    , 
    config
    /
    configuration
    )?
  • Do function names accurately describe what they do?
  • Are similar concepts named similarly across files?
  • 新的命名是否遵循代码库现有的约定？
  • 缩写使用是否一致（不要混用
    repo
    /
    repository
    、
    config
    /
    configuration
    ）？
  • 函数名是否准确描述了其实际功能？
  • 不同文件中相似概念的命名是否统一？

4. Reuse Opportunities

4. 复用机会

  • Is there duplicated logic that could use an existing helper?
  • Are there patterns repeated 3+ times that should be extracted?
  • Can existing utilities, constants, or types be reused instead of redefined?
  • Are there opportunities to consolidate similar functions?
  • 是否存在可以使用现有辅助方法的重复逻辑？
  • 是否存在重复出现3次以上、应当被提取的通用模式？
  • 是否可以复用现有工具、常量或类型，而非重新定义？
  • 是否存在可以合并相似函数的优化机会？

5. TODO & Comment Quality

5. TODO与注释质量

  • Do TODOs follow the project's prefix convention (TODO, TODO_IMPROVE, TODO_TECHDEBT, etc.)?
  • Does each TODO include what and why?
  • Are there stale or resolved TODOs that should be removed?
  • Are comments explaining "why" rather than "what"?
  • Are there missing TODOs for known shortcuts or deferred work?
  • TODO是否遵循项目的前缀约定（TODO、TODO_IMPROVE、TODO_TECHDEBT等）？
  • 每条TODO是否包含做什么和为什么做的说明？
  • 是否存在应该移除的过时或已解决的TODO？
  • 注释是否是解释「为什么」而非「是什么」？
  • 是否存在已知的捷径实现或推迟的工作，缺少对应的TODO标记？

Output Format

输出格式

For each dimension, output:
undefined
针对每个维度，输出如下内容：
undefined

[Dimension Name]

[维度名称]

  • [file:line] — Finding description Suggestion: ...
  • [file:line] — Finding description Suggestion: ...

If a dimension has no findings, output: `No issues found.`
  • [文件:行号] — 发现的问题描述 建议：...
  • [文件:行号] — 发现的问题描述 建议：...

如果某个维度没有发现问题，输出：`No issues found.`

Final Summary

最终总结

End with a prioritized list of the top 3-5 most impactful changes, ranked by effort-to-value ratio.
在输出末尾按照投入产出比排序，列出优先级最高的3-5个影响最大的变更项。