用途
PR Reviewer 是一个用于审查 Pull Request 的技能，按照软件工程原则对代码变更进行详尽检查，并用西班牙语回复 PR 中的评论。
何时使用
- 用户要求“审查 PR”“review PR”“code review”
- 用户要求“分析 PR 变更”
- 用户要求“回复 PR 评论”
- 用户分享 PR 的 URL 或编号
- 用户要求“PR 反馈”或“审查我的变更”
工作流程
第 1 步：检测 PR
尝试自动检测 PR，或向用户询问：
# 选项 1：从当前分支检测 PR
gh pr view --json number,title,url,state,headRefName,baseRefName 2>/dev/null
# 如果失败，向用户询问 URL 或编号
如果用户提供：
- 完整 URL：提取 owner/repo 和编号
- 仅编号：使用当前仓库
- 未提供：尝试从当前分支检测
第 2 步：获取 PR 信息
# PR 元数据
gh pr view {numero} --json number,title,body,author,state,headRefName,baseRefName,additions,deletions,changedFiles
# 完整 diff
gh pr diff {numero}
# 已有评论
gh api repos/{owner}/{repo}/pulls/{numero}/comments --jq '.[] | {id, path, line, body, user: .user.login, created_at}'
# Review 评论（如果有 review）
gh api repos/{owner}/{repo}/pulls/{numero}/reviews --jq '.[] | {id, state, body, user: .user.login}'
第 3 步：分析 diff
对每个修改的文件，检查以下方面：
3.1 安全性
- 硬编码凭据
- SQL 注入
- XSS 漏洞
- 暴露的密钥（.env、API keys）
- 权限不正确
- 缺少输入验证
3.2 代码质量（KISS、DRY、SOLID）
- KISS：不必要的复杂代码
- DRY：应提取的重复逻辑
- 单一职责：函数/类承担过多职责
- 开闭原则：可扩展性违规
- 依赖倒置：本应使用抽象却依赖具体实现
3.3 Bug 与边界情况
- 未处理的 null/undefined
- 竞态条件
- 内存泄漏
- 缺少错误处理
- 差一错误
- 边界条件
3.4 测试
- 新代码缺少测试
- 测试未覆盖边界情况
- 错误的 mock
- 断言过弱
3.5 风格与可维护性
- 命名不具描述性
- 缺少或过多的注释
- 函数过长（>50 行）
- 文件过大（>200 行）
- 未使用常量的魔法数字
第 4 步：回复已有评论
对 PR 中的每一条评论生成回复：
# 单条回复格式
gh pr comment {numero} --body "**Re: @{autor} en \`{archivo}:{linea}\`**
{西班牙语回复}
---
_Respuesta generada por PR Reviewer_"
回复规则：
- 始终使用西班牙语
- 建设性而非破坏性
- 如果评论有效：“好观点，应该……”
- 如果评论不正确：“实际上，这个模式是正确的，因为……”
- 如果需要修改：建议具体代码
- 如果是提问：用清晰的解释回答
第 5 步：生成审查报告
向用户呈现结构化摘要：
## Review del PR #{numero}: {titulo}
### Resumen
- **Archivos modificados**: X
- **Lineas agregadas**: +X
- **Lineas eliminadas**: -X
- **Comentarios respondidos**: X
### Hallazgos por severidad
#### Criticos (bloquean merge)
- [ ] {hallazgo 1}
#### Importantes (deberian arreglarse)
- [ ] {hallazgo 2}
#### Sugerencias (nice to have)
- [ ] {hallazgo 3}
### Archivos revisados
| Archivo | Estado | Notas |
|---------|--------|-------|
| src/foo.ts | Requiere cambios | Falta validacion |
| src/bar.ts | OK | - |
### Comentarios respondidos
1. @usuario en `archivo.ts:42`: "{comentario original}"
- Respuesta: "{mi respuesta}"
第 6 步：发布前确认
重要：在发布评论之前，向用户展示：
Voy a publicar las siguientes respuestas:
1. En archivo.ts:42 - "Buen punto, se deberia..."
2. En otro.ts:15 - "Este patron es correcto porque..."
¿Confirmas que publique estos comentarios? [S/n]
仅在明确确认后才发布。
使用示例
示例 1：自动审查
用户：“审查我的 PR”
- 检测：gh pr view → PR #123 “Add user authentication”
- 获取 diff 和评论
- 按检查清单分析
- 为 3 条已有评论生成回复
- 展示报告并请求确认
- 确认后发布评论
示例 2：指定 PR
用户：“审查 https://github.com/org/repo/pull/456”
- 解析 URL → owner=org, repo=repo, numero=456
- 如需要则切换仓库上下文
- 执行完整审查流程
示例 3：仅回复评论
用户：“回复 PR 789 的评论”
- 获取 PR #789
- 列出已有评论
- 生成回复而不做完整审查
- 确认并发布
有用的 gh 命令
# 查看当前 PR
gh pr view
# 查看 diff
gh pr diff {numero}
# 列出评论
gh api repos/{owner}/{repo}/pulls/{numero}/comments
# 添加一般评论
gh pr comment {numero} --body "texto"
# 在指定行添加评论
gh api repos/{owner}/{repo}/pulls/{numero}/comments \
-f body="comentario" \
-f path="archivo.ts" \
-f line=42 \
-f side="RIGHT"
# 批准 PR
gh pr review {numero} --approve --body "LGTM"
# 请求修改
gh pr review {numero} --request-changes --body "Ver comentarios"
审查原则
建设性语气
- 建议而非命令
- 解释每条建议背后的“为什么”
- 先肯定优点再批评
- 提供具体替代方案
按优先级排列发现
- 安全性（关键）
- Bug（关键）
- 性能（重要）
- 可维护性（重要）
- 风格（建议）
避免
- 模糊评论（“我不喜欢这个”）
- 对偏好的吹毛求疵
- 忽略变更上下文
- 居高临下
限制
该技能依赖 gh CLI 与 GitHub 交互，需要相应的仓库访问权限。发布评论前必须获得用户明确确认。资料未提供其他平台支持、收费或价格信息。