name: pr-reviewer
description: Revisa PRs aplicando KISS, DRY, SOLID. Usa cuando el usuario diga "revisar PR", "code review", "analizar cambios del PR", "responder comentarios del PR", o comparta URL/número de PR.
allowed-tools: Read, Glob, Grep, Bash

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

1. Seguridad (critico)
2. Bugs (critico)
3. Performance (importante)
4. Mantenibilidad (importante)
5. Estilo (sugerencia)

Evitar

• Comentarios vagos ("esto no me gusta")
• Bikeshedding sobre preferencias
• Ignorar el contexto del cambio
• Ser condescendiente