PR Reviewer
Skill para revisar Pull Requests de forma exhaustiva, aplicando principios de ingenieria de software y respondiendo a comentarios en español.
Cuando usar esta Skill
- Usuario pide "revisar PR", "review PR", "code review"
- Usuario pide "analizar cambios" de un PR
- Usuario pide "responder comentarios" de un PR
- Usuario comparte URL de PR o numero de PR
- Usuario pide "PR feedback" o "revisar mis cambios"
Proceso
Paso 1: Detectar PR
Intentar detectar el PR automaticamente o solicitar al usuario:
# Opcion 1: Detectar PR del branch actual
gh pr view --json number,title,url,state,headRefName,baseRefName 2>/dev/null
# Si falla, preguntar al usuario por URL o numero
Si el usuario proporciona:
- URL completa: Extraer owner/repo y numero
- Solo numero: Usar repo actual
- Nada: Intentar detectar del branch actual
Paso 2: Obtener informacion del PR
# Metadata del PR
gh pr view {numero} --json number,title,body,author,state,headRefName,baseRefName,additions,deletions,changedFiles
# Diff completo
gh pr diff {numero}
# Comentarios existentes
gh api repos/{owner}/{repo}/pulls/{numero}/comments --jq '.[] | {id, path, line, body, user: .user.login, created_at}'
# Review comments (si hay reviews)
gh api repos/{owner}/{repo}/pulls/{numero}/reviews --jq '.[] | {id, state, body, user: .user.login}'
Paso 3: Analizar el diff
Para cada archivo modificado, revisar:
3.1 Seguridad
- Credenciales hardcodeadas
- SQL injection
- XSS vulnerabilities
- Secrets expuestos (.env, API keys)
- Permisos incorrectos
- Input validation faltante
3.2 Calidad de codigo (KISS, DRY, SOLID)
- KISS: Codigo innecesariamente complejo
- DRY: Logica duplicada que deberia extraerse
- Single Responsibility: Funciones/clases haciendo demasiado
- Open/Closed: Violaciones de extensibilidad
- Dependency Inversion: Dependencias concretas donde deberian ser abstracciones
3.3 Bugs y edge cases
- Null/undefined sin manejar
- Race conditions
- Memory leaks
- Error handling faltante
- Off-by-one errors
- Boundary conditions
3.4 Testing
- Tests faltantes para nuevo codigo
- Tests que no cubren edge cases
- Mocks incorrectos
- Assertions debiles
3.5 Estilo y mantenibilidad
- Nombres poco descriptivos
- Comentarios faltantes o excesivos
- Funciones muy largas (>50 lineas)
- Archivos muy grandes (>200 lineas)
- Magic numbers sin constantes
Paso 4: Responder a comentarios existentes
Para CADA comentario en el PR, generar una respuesta:
# Formato de respuesta individual
gh pr comment {numero} --body "**Re: @{autor} en \`{archivo}:{linea}\`**
{respuesta en español}
---
_Respuesta generada por PR Reviewer_"
Reglas para respuestas:
- Siempre en ESPAÑOL
- Ser constructivo, no destructivo
- Si el comentario es valido: "Buen punto, se deberia..."
- Si el comentario es incorrecto: "En realidad, este patron es correcto porque..."
- Si requiere cambio: Sugerir codigo concreto
- Si es pregunta: Responder con explicacion clara
Paso 5: Generar reporte de review
Presentar al usuario un resumen estructurado:
## 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}"
Paso 6: Confirmar antes de comentar
IMPORTANTE: Antes de publicar comentarios, mostrar al usuario:
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]
Solo publicar despues de confirmacion explicita.
Ejemplos de uso
Ejemplo 1: Review automatico
Usuario: "Revisame el PR"
1. Detectar: gh pr view → PR #123 "Add user authentication"
2. Obtener diff y comentarios
3. Analizar aplicando checklist
4. Generar respuestas para 3 comentarios existentes
5. Mostrar reporte y pedir confirmacion
6. Publicar comentarios tras confirmacion
Ejemplo 2: PR especifico
Usuario: "Revisa https://github.com/org/repo/pull/456"
1. Parsear URL → owner=org, repo=repo, numero=456
2. Cambiar contexto al repo si es necesario
3. Ejecutar proceso completo de review
Ejemplo 3: Solo responder comentarios
Usuario: "Responde los comentarios del PR 789"
1. Obtener PR #789
2. Listar comentarios existentes
3. Generar respuestas sin hacer review completo
4. Confirmar y publicar
Comandos gh utiles
# Ver PR actual
gh pr view
# Ver diff
gh pr diff {numero}
# Listar comentarios
gh api repos/{owner}/{repo}/pulls/{numero}/comments
# Agregar comentario general
gh pr comment {numero} --body "texto"
# Agregar comentario en linea especifica
gh api repos/{owner}/{repo}/pulls/{numero}/comments \
-f body="comentario" \
-f path="archivo.ts" \
-f line=42 \
-f side="RIGHT"
# Aprobar PR
gh pr review {numero} --approve --body "LGTM"
# Pedir cambios
gh pr review {numero} --request-changes --body "Ver comentarios"
Principios de review
Tono constructivo
- Sugerir, no ordenar
- Explicar el "por que" detras de cada sugerencia
- Reconocer lo bueno antes de criticar
- Ofrecer alternativas concretas
Priorizar hallazgos
- Seguridad (critico)
- Bugs (critico)
- Performance (importante)
- Mantenibilidad (importante)
- Estilo (sugerencia)
Evitar
- Comentarios vagos ("esto no me gusta")
- Bikeshedding sobre preferencias
- Ignorar el contexto del cambio
- Ser condescendiente