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