Code review automático en PRs

El caso estrella de la automatización: que cada PR reciba una revisión sin que nadie la pida. Hay tres formas, de más llave en mano a más a medida — elige según tu plan y control.

Qué opción es para ti

La A está limitada a admins de Team/Enterprise y aún en research preview. La C es la universal: funciona en cualquier sesión de Claude Code, sin GitHub App ni permisos de org. Si solo vas a probar una, empieza por la C.

Opción A · El servicio gestionado (Code Review)

Claude Code ofrece Code Review, un servicio gestionado que analiza tus PRs y postea hallazgos como comentarios inline en las líneas con problemas. Varios agentes especializados revisan el diff en el contexto de todo tu repo en paralelo, buscando bugs de lógica, vulnerabilidades, casos límite y regresiones.

Nota: está en research preview para planes Team y Enterprise, y lo activa un admin una vez para la organización (en claude.ai/admin-settings/claude-code).

Los hallazgos se etiquetan por severidad y no aprueban ni bloquean el PR, así que tu flujo de review actual no cambia:

Por repo eliges cuándo corre: una vez al abrir el PR, en cada push, o manual (@claude review en un comentario del PR).

Afinarlo con REVIEW.md

Pones un REVIEW.md en la raíz y se inyecta como instrucción de máxima prioridad en cada agente de la revisión. Sirve para recalibrar qué es 🔴 Important en tu repo, capar el número de nits, saltarte ficheros generados, o exigir checks propios:

# Review instructions

## Qué es Important aquí
Reserva Important para lógica incorrecta, fugas de datos (PII en logs),
queries sin scope de tenant y migraciones no retrocompatibles. Estilo y
naming son Nit como mucho.

## Capa los nits
Máximo 5 Nits por review; el resto, "y N similares" en el resumen.

## No reportar
- Lo que ya valida CI: lint, formato, tipos
- Ficheros generados bajo `src/gen/` y `*.lock`

## Comprueba siempre
- Toda ruta de API nueva tiene test de integración

(Tu CLAUDE.md también se lee: las violaciones nuevas se marcan como nits.)

Opción B · Self-hosted con la Action

Si quieres correr la revisión en tu propia CI (sin el servicio gestionado, o fuera de Team/Enterprise), usa la GitHub Action de la lección anterior con la skill code-review, disparada en cada PR:

name: Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"

Corre en tus runners, con tu API key, y lo controlas tú entero. (Fíjate: instala un plugin y le pasa una skill — todo lo de los cursos anteriores encajando aquí.)

Opción C · En local, antes del PR

La accesible para todos: revisa el diff antes de abrir el PR, sin GitHub App ni permisos de org. /code-review es una skill incluida en Claude Code; corre en tu sesión:

/code-review

Revisa el diff actual buscando bugs de corrección y reporta hallazgos sin editar tus ficheros (no toca nada, solo informa). La sintaxis completa:

/code-review [low|medium|high|xhigh|max] [--comment] [--fix] [target]

• Nivel de esfuerzo (low … max): los niveles bajos devuelven menos hallazgos pero de más confianza; de high a max, cobertura más amplia con posibles hallazgos inciertos. Sin nivel, usa el esfuerzo actual de la sesión.
• --comment: en vez de imprimir los hallazgos solo en tu terminal, los postea como comentarios inline en el PR de GitHub actual (en las líneas con problemas).
• --fix: aplica los hallazgos a tu working tree tras la revisión (por defecto, sin esta flag, no toca nada).
• target: un path o una referencia de PR, para revisar algo concreto en vez del diff actual.

Ojo con /simplify. Este comando se llamaba /simplify hasta la v2.1.147. Pero desde la v2.1.154 /simplify es un comando distinto: una revisión solo de limpieza (reuse, simplificación, eficiencia) que no caza bugs. O sea, ya no es un alias: para encontrar bugs usa /code-review (con --fix si quieres que además los arregle).

Qué verás

Sin --comment, los hallazgos salen en tu terminal, agrupados por severidad. Algo así (ejemplo ilustrativo):

🔴 Important · src/auth/session.ts:142
   El refresco de token compite con el logout: deja sesiones obsoletas activas.

🟡 Nit · src/auth/session.ts:88
   parseExpiry devuelve 0 sin avisar si el input está mal formado.

Con --comment, ese mismo hallazgo aparece en el PR, anclado a la línea exacta del diff (ejemplo ilustrativo de un comentario inline):

src/auth/session.ts  línea 142

  🔴 Important — El refresco de token compite con el logout, dejando
  sesiones obsoletas activas. Considera cancelar el refresh pendiente
  en el handler de logout.

Cuándo usarla: ejecútala antes de abrir el PR (o antes del último push) para cazar los bugs de corrección en local, mientras aún tienes el contexto fresco. Así llegas al PR con el diff ya saneado, en vez de esperar a que la CI o un revisor los encuentren.

Si falla: si no devuelve nada, revisa que tienes cambios sin commitear o commits por delante de la rama base (sin diff, no hay nada que revisar). Y --comment necesita un PR de GitHub abierto para esa rama; si aún no existe, los hallazgos salen solo en el terminal.

Qué llevas hasta aquí

• Servicio gestionado (Code Review): llave en mano para Team/Enterprise, severidades, afinado con REVIEW.md.
• Action self-hosted: corre la revisión en tu CI con la skill code-review; control total.
• /code-review local (universal): revisa el diff antes de abrir el PR, con nivel de esfuerzo a elegir; --comment lo postea inline en el PR.

En la última lección, el equivalente para quien usa GitLab.

Fuente oficial: Code Review · GitHub Actions