code-reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Reviewer

代码审查工具

This skill guides the agent in conducting professional and thorough code reviews for both local development and remote Pull Requests.
该Skill可指导Agent针对本地开发代码和远程Pull Requests开展专业、全面的代码审查工作。

Workflow

工作流程

1. Determine Review Target

1. 确定审查目标

  • Remote PR: If the user provides a PR number or URL (e.g., "Review PR #123"), target that remote PR.
  • Local Changes: If no specific PR is mentioned, or if the user asks to "review my changes", target the current local file system states (staged and unstaged changes).
  • 远程PR:如果用户提供PR编号或URL(例如“审查PR #123”),则以该远程PR为审查目标。
  • 本地变更:如果未指定具体PR,或者用户要求“审查我的变更”,则以当前本地文件系统状态(已暂存和未暂存的变更)为审查目标。

2. Preparation

2. 准备工作

For Remote PRs:

针对远程PR:

  1. Checkout: Use the GitHub CLI to checkout the PR.
    bash
    gh pr checkout <PR_NUMBER>
  2. Preflight: Execute the project's standard verification suite to catch automated failures early.
    bash
    npm run preflight
  3. Context: Read the PR description and any existing comments to understand the goal and history.
  1. 拉取代码:使用GitHub CLI拉取PR代码。
    bash
    gh pr checkout <PR_NUMBER>
  2. 预检查:执行项目标准验证套件,尽早发现自动化可检测的问题。
    bash
    npm run preflight
  3. 了解上下文:阅读PR描述和已有评论,明确PR目标和历史背景。

For Local Changes:

针对本地变更:

  1. Identify Changes:
    • Check status:
      git status
    • Read diffs:
      git diff
      (working tree) and/or
      git diff --staged
      (staged).
  2. Preflight (Optional): If the changes are substantial, ask the user if they want to run
    npm run preflight
    before reviewing.
  1. 识别变更内容
    • 查看状态:
      git status
    • 查看差异:
      git diff
      (工作区)和/或
      git diff --staged
      (已暂存)。
  2. 预检查(可选):如果变更内容较多,询问用户是否要在审查前运行
    npm run preflight

3. In-Depth Analysis

3. 深度分析

Analyze the code changes based on the following pillars:
  • Correctness: Does the code achieve its stated purpose without bugs or logical errors?
  • Maintainability: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
  • Readability: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines?
  • Efficiency: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
  • Security: Are there any potential security vulnerabilities or insecure coding practices?
  • Edge Cases and Error Handling: Does the code appropriately handle edge cases and potential errors?
  • Testability: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.
基于以下维度分析代码变更:
  • 正确性:代码是否能实现预期目标,不存在bug或逻辑错误?
  • 可维护性:代码是否简洁、结构清晰,便于未来理解和修改?需考量代码可读性、模块化程度以及是否遵循既定设计模式。
  • 可读性:代码是否有恰当的注释(必要时),并且格式是否符合项目编码风格指南?
  • 效率:变更是否引入了明显的性能瓶颈或资源利用低效问题?
  • 安全性:是否存在潜在的安全漏洞或不安全的编码实践?
  • 边界情况与错误处理:代码是否能妥善处理边界情况和潜在错误?
  • 可测试性:新增或修改的代码是否有足够的测试覆盖(即使预检查通过)?建议添加能提升覆盖率或鲁棒性的额外测试用例。

4. Provide Feedback

4. 提供反馈

Structure

结构

  • Summary: A high-level overview of the review.
  • Findings:
    • Critical: Bugs, security issues, or breaking changes.
    • Improvements: Suggestions for better code quality or performance.
    • Nitpicks: Formatting or minor style issues (optional).
  • Conclusion: Clear recommendation (Approved / Request Changes).
  • 摘要:审查的高层级概述。
  • 审查发现
    • 严重问题:bug、安全问题或破坏性变更。
    • 改进建议:针对代码质量或性能的优化建议。
    • 细节问题:格式或轻微风格问题(可选)。
  • 结论:明确的审查结论(批准 / 请求修改)。

Tone

语气

  • Be constructive, professional, and friendly.
  • Explain why a change is requested.
  • For approvals, acknowledge the specific value of the contribution.
  • 保持建设性、专业性和友好性。
  • 说明要求修改的原因。
  • 对于批准的情况,认可贡献的具体价值。

5. Cleanup (Remote PRs only)

5. 清理(仅针对远程PR)

  • After the review, ask the user if they want to switch back to the default branch (e.g.,
    main
    or
    master
    ).
  • 审查完成后,询问用户是否要切换回默认分支(例如
    main
    master
    )。