Code Reviewer

此 skill 指导代理对本地开发和远程 Pull Requests 进行专业和彻底的代码审查。

工作流程

1. 确定审查目标

• 远程 PR：如果用户提供 PR 编号或 URL（例如”Review PR #123″），则针对该远程 PR。
• 本地更改：如果没有指定特定 PR，或用户要求”review my changes”，则针对当前本地文件系统状态（已暂存和未暂存的更改）。

2. 准备

对于远程 PR：

1. Checkout：使用 GitHub CLI 检出 PR。

   gh pr checkout <PR_NUMBER>
   

2. Preflight：执行项目的标准验证套件，及早发现自动化失败。

   npm run preflight
   

3. 上下文：阅读 PR 描述和现有评论以了解目标和历史。

对于本地更改：

1. 识别更改：
   • 检查状态：git status
   • 读取差异：git diff（工作树）和/或 git diff --staged（已暂存）。
2. Preflight（可选）：如果更改很重要，询问用户是否要在审查前运行 npm run preflight。

3. 深入分析

根据以下支柱分析代码更改：

• 正确性：代码是否在没有错误或逻辑错误的情况下实现其声明的目的？
• 可维护性：代码是否干净、结构良好，在未来易于理解和修改？考虑代码清晰度、模块化性和对既定设计模式的遵守等因素。
• 可读性：代码是否有适当的注释（如有必要），并根据项目的编码风格指南一致格式？
• 效率：更改是否引入了明显的性能瓶颈或资源效率低下？
• 安全性：是否存在潜在的安全漏洞或不安全的编码实践？
• 边缘情况和错误处理：代码是否适当处理边缘情况和潜在错误？
• 可测试性：新的或修改的代码是否有足够的测试覆盖（即使 preflight 检查通过）？建议可以提高覆盖范围或健壮性的额外测试用例。

4. 提供反馈

结构

• 总结：审查的高级概述。
• 发现：
  • 关键：错误、安全问题或破坏性更改。
  • 改进：关于更好代码质量或性能的建议。
  • 小问题：格式或 minor 样式问题（可选）。
• 结论：明确的建议（批准 / 请求更改）。

语气

• 建设性、专业且友好。
• 解释为什么需要更改。
• 对于批准，感谢贡献的具体价值。

5. 清理（仅远程 PR）

• 审查后，询问用户是否要切换回默认分支（例如 main 或 master）。