wehub-skill-sync
63 lines
2.9 KiB
Markdown
63 lines
2.9 KiB
Markdown
---
|
||
name: code-reviewer
|
||
description: 使用本技能进行代码审查。它既支持本地更改（暂存区或工作树），也支持远程 Pull Request（通过 ID 或 URL）。审查重点在于正确性、可维护性以及对项目标准的遵循情况。
|
||
---
|
||
|
||
# 代码审查员
|
||
|
||
本技能引导代理对本地开发中的更改和远程 Pull Request 进行专业、彻底的代码审查。
|
||
|
||
## 工作流程
|
||
|
||
### 1. 确定审查目标
|
||
* **远程 PR**：如果用户提供了 PR 编号或 URL（例如「审查 PR #123」），则以该远程 PR 为目标。
|
||
* **本地更改**：如果没有提及特定的 PR，或者用户要求「审查我的更改」，则以当前本地文件系统的状态（暂存和未暂存的更改）为目标。
|
||
|
||
### 2. 准备工作
|
||
|
||
#### 针对远程 PR：
|
||
1. **检出**：使用 GitHub CLI 检出该 PR。
|
||
```bash
|
||
gh pr checkout <PR_NUMBER>
|
||
```
|
||
2. **预检**：执行项目的标准验证套件，尽早发现自动化失败项。
|
||
```bash
|
||
npm run preflight
|
||
```
|
||
3. **上下文**：阅读 PR 描述和任何已有的评论，以了解其目标和历史。
|
||
|
||
#### 针对本地更改：
|
||
1. **识别更改**：
|
||
* 检查状态：`git status`
|
||
* 读取差异：`git diff`（工作树）和/或 `git diff --staged`（暂存区）。
|
||
2. **预检（可选）**：如果更改量较大，询问用户是否希望在审查前运行 `npm run preflight`。
|
||
|
||
### 3. 深入分析
|
||
从以下几个维度分析代码更改：
|
||
|
||
* **正确性**：代码是否实现了其声称的目的，没有缺陷或逻辑错误？
|
||
* **可维护性**：代码是否整洁、结构良好、易于理解和将来修改？考虑代码清晰度、模块化程度以及对既定设计模式的遵循情况。
|
||
* **可读性**：代码注释是否得当（必要时），且格式是否符合项目的编码风格指南？
|
||
* **效率**：更改是否引入了明显的性能瓶颈或资源浪费？
|
||
* **安全性**：是否存在潜在的安全漏洞或不安全的编码实践？
|
||
* **边界情况与错误处理**：代码是否妥善处理了边界情况和潜在错误？
|
||
* **可测试性**：新增或修改的代码是否得到了测试的充分覆盖（即使预检已通过）？建议能提高覆盖率或健壮性的额外测试用例。
|
||
|
||
### 4. 提供反馈
|
||
|
||
#### 结构
|
||
* **摘要**：审查的总体概述。
|
||
* **发现**：
|
||
* **严重**：缺陷、安全问题或破坏性更改。
|
||
* **改进**：针对更好的代码质量或性能的建议。
|
||
* **小细节**：格式或微小的样式问题（可选）。
|
||
* **结论**：明确的建议（批准 / 请求修改）。
|
||
|
||
#### 语气
|
||
* 保持建设性、专业且友好。
|
||
* 解释*为什么*要求某项更改。
|
||
* 对于批准，明确肯定该贡献的具体价值。
|
||
|
||
### 5. 清理（仅限远程 PR）
|
||
* 审查完成后，询问用户是否要切回默认分支（例如 `main` 或 `master`）。
|