Qué es /code-review de Claude Code: cómo usarlo, cómo elegir el nivel, el precio de ultra, sus desventajas y los resultados de probarlo de verdad

/code-review de Claude Code es un comando que lee el diff que tienes ahora mismo (los cambios sin confirmar y los commits que van por delante de upstream), busca errores de corrección y te los informa. Es una skill integrada que viene con Claude Code, así que puedes ejecutarla directamente desde la terminal sin instalar ninguna app de GitHub. Si escribes /review, se ejecuta lo mismo.

Este artículo se basa en el texto original de la documentación oficial de Claude Code (la sección «Review a diff locally» de Code Review, Find bugs with ultrareview y Commands) y en el CHANGELOG para explicar qué hace, cómo elegir entre los niveles (de low a max) y ultra, y cómo usar --fix y --comment. Todas las especificaciones que se describen aquí se comprobaron con el texto original a 2 de octubre de 2026. Las secciones 9 y 10 cuentan además qué pasó cuando ejecuté de verdad /code-review high sobre el código de este sitio y las desventajas que encontré por el camino.

1. Qué es /code-review: una skill integrada que busca errores en tu diff

La referencia de comandos (Commands) lo describe en inglés así: «Review the current diff, or a PR number, branch, or path you pass, for correctness bugs», es decir, revisa el diff actual, o el número de PR, la rama o la ruta que le pases, en busca de errores de corrección. Añade que, según el modelo y el nivel de esfuerzo, la revisión también cubre oportunidades de limpieza, y la página de Code Review indica que informa de errores de corrección y de mejoras de reutilización, simplificación y eficiencia. Buscar errores es su trabajo principal; las propuestas de limpieza llegan o no según las condiciones.

La sintaxis es esta:

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [pr#|branch|path]

Conviene conocer cuatro características desde el principio:

• Se ejecuta en segundo plano. La revisión corre como un subagente con su propia ventana de contexto, así que no llena tu conversación. Los hallazgos llegan a la conversación cuando termina.
• Lee CLAUDE.md, pero no REVIEW.md. REVIEW.md es el archivo de instrucciones de la versión de Code Review como app de GitHub, de la que hablo más abajo.
• /review es un alias. Según la documentación, antes de la v2.1.223 /review era un comando aparte que leía un PR de GitHub en una sola pasada. Hoy es lo mismo que /code-review.
• Antes se llamaba /simplify. Según el CHANGELOG, /simplify pasó a llamarse /code-review en la v2.1.147, y más tarde /simplify volvió como un comando independiente que solo hace limpieza y no busca errores.

En la terminal y en las ejecuciones con -p, los hallazgos vuelven como texto en la respuesta. En las apps que piden una lista de hallazgos, como la app de escritorio, se muestran como una lista en la que cada entrada tiene la ubicación en el archivo, un resumen de una frase y una etiqueta de categoría como correctness. Cuando Claude los corrige después, cada entrada queda marcada como corregida, omitida o sin cambios necesarios.

2. Uso básico: elegir qué revisar

La forma más básica es escribirlo sin argumentos en la sesión en la que estás trabajando.

# Revisa los commits por delante de upstream + los cambios sin confirmar
/code-review

# Revisa con un nivel concreto
/code-review high

# Pasa un número de PR para revisar el pull request de un compañero
/code-review high 1234

# Pasa un rango de ramas
/code-review main...my-feature

Sin argumentos, el objetivo son, según la documentación, los commits de tu rama que van por delante de su upstream más cualquier cambio sin confirmar. Si no hay nada nuevo en la rama ni en el árbol de trabajo, no tendrá nada que informar. Para revisar otra cosa, pásale un objetivo:

Salvo que añadas ultra, todo lo que queda después del nivel y los flags se trata como objetivo de la revisión. Por ejemplo, /code-review /fix-issue 123 no carga /fix-issue como una segunda skill, sino que lee el texto /fix-issue 123 como objetivo.

En estos casos se ejecuta en primer plano, dentro de tu conversación, en lugar de en segundo plano: cuando lo vuelves a lanzar mientras una revisión anterior sigue en curso, en modo no interactivo con -p o con el Agent SDK, y cuando pones la variable de entorno CLAUDE_CODE_DISABLE_BACKGROUND_TASKS a 1 (lo que también desactiva todas las demás funciones en segundo plano).

3. Cómo elegir el nivel: de low a max

El nivel es un equilibrio entre lo amplio que mira la revisión y lo seguros que deben ser sus hallazgos. La documentación explica que en low y medium la revisión solo informa de los hallazgos de los que está más segura, así que ves menos falsos positivos, mientras que de high a max amplía la cobertura y puede incluir hallazgos de los que está menos segura.

La regla práctica es cuánto esfuerzo puedes dedicar a leer los hallazgos. Si quieres una comprobación rápida entre tareas, usa low o medium; si quieres atrapar más antes de hacer merge y puedes permitirte descartar tú mismo los falsos positivos, usa high o superior. Ese reparto sigue la descripción de la documentación. Que los niveles altos consuman más tokens es la misma idea que el esfuerzo en general, pero la documentación oficial no da cifras de tiempo ni de uso por nivel. Qué significa el esfuerzo en sí se explica en nuestro artículo sobre el ajuste de esfuerzo de Claude Code.

Si no indicas el nivel, reutiliza «el último que escribiste»

Si no escribes un nivel, la revisión usa el último nivel de low a max que escribiste tú mismo. Eso incluye uno escrito en una sesión anterior, en cuyo caso verás un aviso como Reusing high effort, the level you typed last time. Los detalles:

• El nivel recordado se actualiza cuando escribes algo como /code-review high en una sesión interactiva.
• Un nivel pasado en una ejecución no interactiva con -p no se recuerda.
• ultra ni usa ni actualiza el nivel recordado.
• Si nunca has escrito un nivel, se usa el esfuerzo actual de la sesión.

La documentación también aclara que, antes de la v2.1.223, un /code-review sin nivel siempre usaba el esfuerzo actual de la sesión. Si lo omites esperando el comportamiento antiguo, puede ejecutarse con un nivel más alto (o más bajo) del que esperas, así que si te importa, escribe el nivel cada vez.

4. Cómo usar --fix y --comment

Puede que /rewind no deshaga --fix

Esta es la parte que hay que vigilar más de cerca. Según la documentación, las ediciones que hace --fix en una revisión en segundo plano ocurren fuera de los checkpoints de tu sesión, así que /rewind no las deshace. Para revertirlas, usa git. Cuando la revisión se ejecuta en primer plano (una revisión anterior todavía en curso, -p, etc.), edita durante tu propio turno, así que /rewind las restaura como de costumbre.

# Haz commit del estado actual antes de --fix para poder volver fácilmente
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# Si no te gusta el resultado, deshazlo con git
git diff
git restore .

También puedes ejecutar la revisión sin --fix, leer los resultados y luego pedir «corrige solo el 1 y el 3». Si no tienes claro que haya que aplicar todos los hallazgos, ese es el camino más seguro. Los checkpoints se explican en detalle en nuestro artículo sobre los checkpoints y /rewind.

Dónde publica --comment

• Pull requests de GitHub: publica los hallazgos como comentarios en línea en las líneas correspondientes.
• Merge requests de GitLab: los publica como una sola nota a través de glab, la CLI de GitLab (v2.1.257 o posterior). Si glab no está instalado, los hallazgos solo se muestran en la terminal.

En GitLab, pasa el MR como URL o en la forma !123. Un número suelto o un nombre de rama solo se trata como MR cuando el origin está en gitlab.com; en una instancia de GitLab autogestionada, la documentación indica usar la URL o !123. Si publicar en GitHub requiere autenticación como gh no figura en la documentación oficial a 2 de octubre de 2026.

5. ultra: revisión multiagente en la nube y precio

/code-review ultra es una revisión a fondo que ejecuta varios agentes revisores en paralelo en un sandbox en la nube de Anthropic, no en tu máquina. Es una research preview llamada ultrareview y, en las cuentas donde está disponible, /ultrareview es un alias. La documentación oficial enumera tres ventajas frente a un /code-review local:

• Más señal: cada hallazgo informado se reproduce y verifica de forma independiente, así que los resultados se centran en errores reales y no en sugerencias de estilo.
• Más cobertura: más agentes exploran el cambio en paralelo, lo que saca a la luz problemas que una revisión local puede pasar por alto.
• Sin recursos locales: se ejecuta en la nube, así que mientras tanto puedes seguir trabajando en tu terminal.

Precio y ejecuciones gratuitas

ultra se cobra de los créditos de uso (extra usage), no del uso incluido en tu plan.

• Ejecuciones gratuitas: las tres de Pro y Max son una asignación única por cuenta y no se renuevan.
• Coste por ejecución: cuando se acaban las gratuitas, suele costar entre 5 y 25 $ en créditos de uso, según el tamaño del cambio. El diálogo de lanzamiento muestra una estimación antes de cada ejecución.
• Cómo se cuentan: una ejecución cuenta en cuanto se inicia la sesión en la nube. Detenerla a medias o que falle también gasta una ejecución gratuita. Las revisiones de pago se cobran por lo que realmente se ejecutó.
• Requisito previo: las revisiones de pago no se lanzan si los créditos de uso no están activados. Puedes comprobarlo con /usage-credits. La confirmación para cobrar en créditos de uso aparece una vez por conversación.

Que «5–25 $» sea caro o barato depende de con qué lo compares. Frente a /code-review de low a max, que se queda dentro de los límites de tu plan sin cargo aparte, ultra es un gasto adicional. Frente a la versión de Code Review como app de GitHub que se describe más abajo (una media de 15–25 $ por revisión), en cambio, los rangos de precio se solapan. Pero Code Review es un sistema distinto que se ejecuta automáticamente en cada PR, y las cifras se expresan de forma diferente («media» frente a «rango típico»), así que no se pueden comparar directamente.

Tiempo, alcance y dónde no está disponible

• Duración: normalmente de 5 a 10 minutos. Se ejecuta en segundo plano y puedes consultarla o detenerla con /tasks. Si la detienes, no devuelve resultados parciales.
• Alcance: sin argumentos, revisa tu rama actual frente a la rama por defecto del repositorio, más los cambios sin confirmar y los preparados (staged). Es una base distinta de la del /code-review local, que mira lo que va «por delante de upstream». Pasa un nombre de rama, como en /code-review ultra develop, para cambiar la base.
• Revisar un PR: pasa un número, como en /code-review ultra 1234, y no se sube nada desde tu máquina; la nube clona el PR directamente. Funciona con github.com y con GitHub Enterprise Server conectado.
• Límites: una revisión de rama cubre por defecto hasta 500 archivos modificados y 8.000 líneas modificadas (la documentación indica que estos valores pueden cambiar).
• Dónde no está disponible: requiere iniciar sesión con una cuenta de claude.ai, y no está disponible a través de Amazon Bedrock, Agent Platform de Google Cloud ni Microsoft Foundry, ni para organizaciones con Zero Data Retention. Cuando no está disponible, /code-review ultra se ejecuta como una revisión local.

Una revisión de rama empaqueta el estado de tu repositorio local y lo sube a la nube. Los cambios sin confirmar en archivos con nombres que parecen credenciales, como .env y *.tfvars, siguen las mismas reglas que al subir a una sesión en la nube. Cómo funcionan las sesiones en la nube en general se explica en nuestro artículo sobre las sesiones en la nube.

Publicar los resultados en el PR (--post) y lanzarlo desde scripts

Cuando revisas un PR de github.com con ultra, puedes publicar los resultados en el PR como un único comentario desde tu propia cuenta de GitHub (v2.1.227 o posterior). Es un comentario normal, no una review ni una aprobación, y por defecto no se publica (--no-post). /code-review ultra 1234 --post deja marcada la publicación en el diálogo de lanzamiento, pero aun así tienes que confirmar antes de que empiece. La publicación se hace cuando termina la revisión, así que tienes que mantener la sesión abierta hasta que acabe.

Para CI o scripts, usa el subcomando claude ultrareview. Espera a los resultados y los escribe en stdout (con --json, --timeout (45 minutos por defecto) y --post disponibles). claude -p '/code-review ultra' solo lanza la revisión y termina sin esperar, así que no obtienes los resultados, y cuando hace falta cobrar en créditos de uso ni siquiera se lanza.

# Revisa el PR 1234 con ultra desde un script y obtén los resultados
claude ultrareview 1234

# Usa una base distinta de la rama por defecto
claude ultrareview origin/main

6. En qué se diferencia de funciones parecidas

Claude Code tiene varias funciones de revisión con nombres parecidos. La función de la app de GitHub llamada «Code Review» es especialmente fácil de confundir, porque está documentada en la misma página que el comando /code-review.

• /simplify: cuatro agentes revisan en paralelo la reutilización de helpers existentes, la simplificación, la eficiencia y si el cambio está en el nivel de abstracción adecuado, y luego aplican las correcciones. No busca errores de corrección. La página de Code Review también aconseja que, si tenías /simplify en scripts para buscar errores, pases a /code-review --fix.
• /security-review: revisa el diff entre tu rama actual y la rama por defecto de origin en busca de vulnerabilidades como inyecciones, problemas de autenticación y exposición de datos. Requiere un remoto origin.
• Code Review (app de GitHub): cuando un Owner de la organización la activa, varios agentes en la infraestructura de Anthropic examinan un PR al abrirse, en cada push o cuando alguien escribe @claude review, y dejan comentarios a nivel de línea. Es una research preview solo para Team y Enterprise (no disponible para organizaciones con Zero Data Retention). El precio crece con los tokens, con una media de 15–25 $ por revisión; tarda 20 minutos de media y se cobra de los créditos de uso, aparte de los límites del plan. Puedes ajustar lo que señala con REVIEW.md.
• claude-code-action: ejecuta Claude Code en workflows de GitHub Actions de tu propio repositorio. El ejemplo de revisión de la documentación oficial llama a la versión en plugin de la skill code-review (/code-review:code-review --comment) para comentar en el PR. El coste es el precio de la API de Claude (o los tokens de la suscripción) más el tiempo de ejecución de GitHub Actions.

Ordenarlas por «dónde se ejecuta, quién paga y qué mira» aclara las cosas. Para comprobar tu propio diff en local, usa /code-review; para mirar a fondo antes de hacer merge, usa ultra; para que se ejecute automáticamente en cada PR del equipo, usa Code Review de la app de GitHub o claude-code-action.

7. Cuándo lo inicia Claude por su cuenta y cómo evitarlo

Claude puede iniciar /code-review por su cuenta. Si le pides con lenguaje natural que revise tus cambios, puede ejecutar la skill sin que escribas el comando, y una tarea programada con /code-review como prompt también lanza una revisión. Eso sí, una tarea programada nunca lanza ultra (la revisión en la nube). ultra solo se ejecuta cuando escribes tú mismo /code-review ultra.

Para impedir que lo inicien tanto Claude como las tareas programadas, pero seguir pudiendo usarlo cuando lo escribes tú, añade lo siguiente a un archivo de configuración como ~/.claude/settings.json:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

Las revisiones en segundo plano se ejecutan como subagentes. Cómo manejan los subagentes el contexto y los modelos se explica en nuestro artículo sobre subagentes y equipos de agentes.

8. Qué usar en cada momento

La tabla comparativa de la documentación oficial dice que el /code-review local es lo mejor para obtener comentarios rápidos mientras iteras, y ultra para tener confianza antes del merge en cambios sustanciales. Llevado a un flujo de trabajo cotidiano, queda así:

Como las 3 ejecuciones gratuitas de ultra no se renuevan, compensa reservarlas para cambios con un gran radio de impacto, o cambios en los que la revisión local no resolvió la duda, en lugar de para correcciones pequeñas. Del mismo modo, usa /security-review cuando quieras centrarte en vulnerabilidades y /simplify cuando quieras mejorar la legibilidad en lugar de buscar errores; repartirlos por propósito es como los describe la documentación.

9. Lo probé con el código de este sitio

El 2 de octubre de 2026 ejecuté /code-review high sobre el código del detector de imágenes IA que publicamos en este sitio. La herramienta lee los metadatos y la procedencia (C2PA) de una imagen por completo dentro del navegador, y el objetivo fueron cuatro archivos: la lógica de la interfaz, la lógica de análisis (un Web Worker), el controlador y la plantilla de la página. Lo ejecuté en la app de escritorio de Claude Code (Claude Code 2.1.284 integrado, modelo Opus 5.5), justo después de haber buscado errores yo mismo y haber corregido cinco.

Cada hallazgo llegó con la forma «qué archivo, qué línea» y «qué entrada provoca qué». Comprobé cada uno con el código fuente de la biblioteca que usa la herramienta para leer los metadatos de las imágenes (exifr) y con imágenes de prueba que preparé yo, y corregí los 9 que resultaron ser reales. Los principales:

Así que, incluso justo después de haber buscado y corregido yo mismo, seguían ahí 9 errores de otro tipo. Sobre todo, los hallazgos sobre suposiciones («la biblioteca debería comportarse así») eran difíciles de detectar sin leer el código fuente de la biblioteca. Dicho esto, es el resultado de una sola ejecución sobre un solo código. No tiene por qué encontrar errores reales en la misma proporción cada vez, y no lo comparé con low, medium ni max, ni probé el ultra de pago.

10. Desventajas y precauciones

Tras usarlo y leer la documentación oficial, estas son cinco cosas a tener en cuenta:

• Gasta tus límites. Las revisiones locales también salen de tu uso normal de Claude, y los niveles altos gastan más. Con ultra, cuando los usuarios de Pro y Max agotan las 3 ejecuciones gratuitas (Team y Enterprise desde el principio), pagan unos 5–25 $ por ejecución en créditos de uso.
• No te fíes de los hallazgos sin más. La propia documentación dice que de high para arriba puede haber hallazgos menos seguros. Esta vez fueron reales 9 de 10, pero comprobar cada uno sigue llevando trabajo.
• --fix no se puede deshacer con /rewind. Los cambios hechos en segundo plano hay que revertirlos con git, así que haz commit antes de usarlo.
• Solo comprueba la corrección del código. No comprueba si el contenido de un texto o de una configuración se ajusta a los hechos. Por ejemplo, un problema habitual en este sitio, que «el artículo dice algo distinto de la especificación oficial», queda fuera de su alcance.
• Claude puede iniciarlo por su cuenta. Si no quieres que pase, el ajuste de la sección 7 lo limita a ejecuciones manuales.

Mi conclusión: ejecutarlo una vez en high después de escribir código nuevo o de hacer un cambio grande fue el uso que justificó el esfuerzo y el consumo. En cambio, no encaja con ediciones de texto ni con cambios pequeños de configuración.

Resumen

/code-review es una skill integrada que revisa tu diff local o un PR centrándose en errores de corrección. Se ejecuta en segundo plano para no interrumpir tu trabajo, y su coste se queda dentro de tu uso normal. En low o medium solo obtienes los hallazgos más seguros; de high a max la búsqueda es más amplia, pero tienes que filtrar los resultados; y si no indicas el nivel, reutiliza el último que escribiste.

--fix, que llega hasta corregir, es cómodo, pero las ediciones en segundo plano no se pueden deshacer con /rewind, así que lo prudente es hacer commit antes. Cuando quieras mirar más a fondo, ultra dedica unos 5 a 10 minutos en la nube y devuelve solo hallazgos verificados; Pro y Max tienen 3 ejecuciones gratuitas únicas, y después cuesta unos 5–25 $ por ejecución en créditos de uso. Code Review de la app de GitHub y claude-code-action, de nombre parecido, son cosas distintas, tanto por dónde se ejecutan como por lo que cuestan.

Cuando lo ejecuté una vez sobre el código de este sitio, 9 de sus 10 hallazgos eran errores reales, incluso justo después de haber corregido cosas yo mismo. Hay que comprobar cada hallazgo, pero merece mucho la pena ejecutarlo una vez después de escribir código nuevo o de hacer un cambio grande.

Preguntas frecuentes

P. ¿En qué se diferencian /review y /code-review?

R. Ahora son lo mismo. /review es un alias de /code-review y admite los mismos niveles y flags. Según la documentación oficial, antes de la v2.1.223 /review era un comando aparte, de solo lectura, que revisaba un PR de GitHub en una sola pasada.

P. ¿Usar /code-review cuesta dinero extra?

R. No de low a max. En la tabla comparativa de la documentación oficial, su coste cuenta dentro del uso normal. El que cuesta extra es ultra: tras las 3 ejecuciones gratuitas de Pro y Max, son unos 5–25 $ por ejecución en créditos de uso.

P. ¿Las 3 ejecuciones gratuitas de ultra se renuevan cada mes?

R. No. La documentación oficial describe las tres ejecuciones de Pro y Max como una asignación única por cuenta que no se renueva. Las revisiones que detienes a medias o que fallan también cuentan como una ejecución. Team y Enterprise no tienen ejecuciones gratuitas.

P. ¿Puedo deshacer los cambios que hace --fix?

R. Usa git. Las ediciones de una revisión que se ejecutó en segundo plano ocurren fuera de tus checkpoints, así que /rewind no las deshace. Si la revisión se ejecutó en primer plano (una revisión anterior todavía en curso, -p, etc.), /rewind sí puede restaurarlas. Ante la duda, haz commit antes de usar --fix.

P. ¿Las reglas de REVIEW.md se aplican a /code-review?

R. No. El /code-review local sigue CLAUDE.md, pero no lee REVIEW.md. REVIEW.md es el archivo de instrucciones de la versión de Code Review como app de GitHub. Pon en CLAUDE.md las reglas que quieras que siga la revisión local.

Fuentes

• Documentación oficial de Claude Code: Code Review (incluida la sección «Review a diff locally»)
• Documentación oficial de Claude Code: Find bugs with ultrareview
• Documentación oficial de Claude Code: Commands
• Documentación oficial de Claude Code: Claude Code GitHub Actions
• Claude Code: CHANGELOG

Todas las fuentes se comprobaron con el texto original el 2 de octubre de 2026. La documentación oficial indica que ultrareview es una research preview y que sus funciones, su precio y su disponibilidad pueden cambiar.