Code Reviewer
此 skill 指导代理对本地开发和远程 Pull Requests 进行专业和彻底的代码审查。
工作流程
1. 确定审查目标
- 远程 PR：如果用户提供 PR 编号或 URL（例如"Review PR #123"），则针对该远程 PR。
- 本地更改：如果没有指定特定 PR，或用户要求"review my changes"，则针对当前本地文件系统状态（已暂存和未暂存的更改）。
2. 准备
对于远程 PR：
- Checkout：使用 GitHub CLI 检出 PR。
gh pr checkout <PR_NUMBER> - Preflight：执行项目的标准验证套件，及早发现自动化失败。
npm run preflight - 上下文：阅读 PR 描述和现有评论以了解目标和历史。
对于本地更改：
- 识别更改：
- 检查状态：git status - 读取差异：git diff（工作树）和/或 git diff --staged（已暂存）。
- Preflight（可选）：如果更改很重要，询问用户是否要在审查前运行
npm run preflight。
3. 深入分析
根据以下支柱分析代码更改：
- 正确性：代码是否在没有错误或逻辑错误的情况下实现其声明的目的？
- 可维护性：代码是否干净、结构良好，在未来易于理解和修改？考虑代码清晰度、模块化性和对既定设计模式的遵守等因素。
- 可读性：代码是否有适当的注释（如有必要），并根据项目的编码风格指南一致格式？
- 效率：更改是否引入了明显的性能瓶颈或资源效率低下？
- 安全性：是否存在潜在的安全漏洞或不安全的编码实践？
- 边缘情况和错误处理：代码是否适当处理边缘情况和潜在错误？
- 可测试性：新的或修改的代码是否有足够的测试覆盖（即使 preflight 检查通过）？建议可以提高覆盖范围或健壮性的额外测试用例。
4. 提供反馈
结构
- 总结：审查的高级概述。
- 发现：
- 关键：错误、安全问题或破坏性更改。 - 改进：关于更好代码质量或性能的建议。 - 小问题：格式或 minor 样式问题（可选）。
- 结论：明确的建议（批准 / 请求更改）。
语气
- 建设性、专业且友好。
- 解释为什么需要更改。
- 对于批准，感谢贡献的具体价值。
5. 清理（仅远程 PR）
- 审查后，询问用户是否要切换回默认分支（例如
main或master）。