SuperAPI AI Directory
Partner中文AI newsFavorites
Skillspr-reviewer

pr-reviewer

Coding & development

View repository

Updated 10-16 04:05

About this skill

PR Reviewer

Skill to review Pull Requests exhaustively, applying software engineering principles and responding to comments in Spanish.

When to use this Skill

  • User asks to "revisar PR", "review PR", "code review"
  • User asks to "analizar cambios" of a PR
  • User asks to "responder comentarios" of a PR
  • User shares a PR URL or PR number
  • User asks for "PR feedback" or "revisar mis cambios"

Process

Step 1: Detect PR

Try to detect the PR automatically or ask the user:

# 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

If the user provides:

  • Full URL: Extract owner/repo and number
  • Number only: Use current repo
  • Nothing: Try to detect from the current branch

Step 2: Get PR information

# 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}'

Step 3: Analyze the diff

For each modified file, review:

3.1 Security

  • Hardcoded credentials
  • SQL injection
  • XSS vulnerabilities
  • Exposed secrets (.env, API keys)
  • Incorrect permissions
  • Missing input validation

3.2 Code quality (KISS, DRY, SOLID)

  • KISS: Unnecessarily complex code
  • DRY: Duplicated logic that should be extracted
  • Single Responsibility: Functions/classes doing too much
  • Open/Closed: Extensibility violations
  • Dependency Inversion: Concrete dependencies where they should be abstractions

3.3 Bugs and edge cases

  • Null/undefined unhandled
  • Race conditions
  • Memory leaks
  • Missing error handling
  • Off-by-one errors
  • Boundary conditions

3.4 Testing

  • Missing tests for new code
  • Tests that do not cover edge cases
  • Incorrect mocks
  • Weak assertions

3.5 Style and maintainability

  • Unclear names
  • Missing or excessive comments
  • Very long functions (>50 lines)
  • Very large files (>200 lines)
  • Magic numbers without constants

Step 4: Respond to existing comments

For EACH comment in the PR, generate a response:

# Formato de respuesta individual
gh pr comment {numero} --body "**Re: @{autor} en \`{archivo}:{linea}\`**

{respuesta en español}

---
_Respuesta generada por PR Reviewer_"

Rules for responses:

  • Always in SPANISH
  • Be constructive, not destructive
  • If the comment is valid: "Buen punto, se deberia..."
  • If the comment is incorrect: "En realidad, este patron es correcto porque..."
  • If it requires a change: Suggest concrete code
  • If it is a question: Respond with a clear explanation

Step 5: Generate review report

Present a structured summary to the user:

## 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}"

Step 6: Confirm before commenting

IMPORTANT: Before posting comments, show the user:

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]

Only post after explicit confirmation.

Usage examples

Example 1: Automatic review

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

Example 2: Specific PR

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

Example 3: Only reply to comments

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

Useful gh commands

# 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"

Review principles

Constructive tone

  • Suggest, don't order
  • Explain the "why" behind each suggestion
  • Acknowledge the good before criticizing
  • Offer concrete alternatives

Prioritize findings

  1. Security (critical)
  2. Bugs (critical)
  3. Performance (important)
  4. Maintainability (important)
  5. Style (suggestion)

Avoid

  • Vague comments ("I don't like this")
  • Bikeshedding over preferences
  • Ignoring the context of the change
  • Being condescending