> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Revisa localmente con /code-review

> Ejecuta `/code-review` en una sesión de Claude Code para encontrar bugs en los cambios de tu rama, apunta la revisión a un pull request o una ruta, y haz que Claude aplique las correcciones.

`/code-review` es un comando que escribes en el prompt de Claude Code, en la sesión donde estás trabajando. Claude revisa los cambios de tu rama, busca bugs de corrección e informa lo que encontró en tu conversación. Según tu modelo y tu nivel de esfuerzo, la revisión también abarca limpiezas de reutilización, simplificación y eficiencia.

El comando funciona en cualquier plan. La revisión se ejecuta en tu propia sesión, así que cuenta para el uso de tu plan o la facturación de la API de la misma manera que el resto de la sesión.

<Note>
  Para que cada pull request de un repositorio se revise automáticamente en GitHub, consulta [Code Review](/docs/es/code-review), un servicio administrado que un Owner activa para tu organización.
</Note>

`/review` es un alias de `/code-review`. Antes de la v2.1.223, `/review` era un comando independiente que ejecutaba una revisión de una sola pasada y de solo lectura de un pull request de GitHub.

<Steps>
  <Step title="Ejecuta /code-review">
    Ejecuta el comando:

    ```text theme={null}
    /code-review
    ```

    Sin un objetivo, la revisión abarca los cambios de tu rama actual. Para apuntar la revisión a un pull request, otra rama, una ruta o un rango de commits, consulta [Elige qué revisar](#choose-what-to-review).

    También puedes agregar flags:

    * `--fix`: también le pide a Claude que aplique los hallazgos a tu árbol de trabajo después de la revisión. Sus ediciones pasan por tu [modo de permisos](/docs/es/permission-modes).
    * `--comment`: publica los hallazgos en un pull request de GitHub como comentarios en línea, o en un [merge request de GitLab](#post-findings-to-a-gitlab-merge-request) como una sola nota
  </Step>

  <Step title="Sigue trabajando">
    La revisión se ejecuta como un [subagente](/docs/es/sub-agents) en segundo plano con su propia ventana de contexto, así que no llena tu conversación. Los hallazgos llegan a tu conversación cuando la revisión termina.
  </Step>

  <Step title="Actúa sobre los hallazgos">
    Pídele a Claude que corrija lo que encontró la revisión. Con `--fix` o `--comment`, Claude aplica o publica los hallazgos como parte de la revisión, y es posible que se te pida aprobar sus ediciones.
  </Step>
</Steps>

<h2 id="choose-what-to-review">
  Elige qué revisar
</h2>

Para revisar algo distinto de tu rama actual, escribe un objetivo después del nivel de esfuerzo y de cualquier flag. Claude recibe ese texto como el objetivo de la revisión. Un objetivo puede ser un número de pull request, un nombre de rama, una ruta de archivo o un rango de revisiones de Git. Busca lo que quieres revisar en la primera columna y escribe lo que muestra la segunda columna:

| Para apuntar la revisión a | Escribe |
| :- | :- |
| Tu rama actual y los cambios sin commit | `/code-review` |
| Tus últimos 15 commits | `/code-review HEAD~15..HEAD` |
| Una rama frente a otra | `/code-review main...my-feature` |
| Un solo commit, donde `abc1234` es el hash del commit | `/code-review abc1234^..abc1234` |
| Un pull request por número | `/code-review 1234` |
| Una ruta de archivo o directorio | `/code-review src/auth` |

Sin un objetivo, `/code-review` revisa los commits de tu rama que van por delante de su rama upstream, además de tus cambios sin commit. Si la rama no tiene upstream, Claude compara con `main`, o con el commit anterior.

Con `ultra`, Claude Code interpreta el objetivo de otra manera, como se describe en [Texto después del nivel de esfuerzo y los flags](#text-after-the-effort-level-and-flags).

<h2 id="what-the-review-reads-and-edits">
  Qué lee y edita la revisión
</h2>

Revisa estos puntos antes de ejecutar una revisión, especialmente con `--fix`:

* **Ediciones**: sin `--fix`, las instrucciones de la revisión le piden a Claude solo un informe. Con `--fix`, también le piden que aplique los hallazgos a tu árbol de trabajo. En cualquier caso, toda edición pasa por tu modo de permisos.
* **Retroceder**: una revisión en segundo plano aplica sus ediciones de `--fix` fuera de los [checkpoints](/docs/es/checkpointing#subagent-edits-not-restored) de tu sesión. Después de una, `/rewind` restaura solo los archivos que Claude ya había editado en tu conversación. Las ediciones de la revisión en otros archivos se mantienen, así que usa git para revertirlas. Cuando la revisión [se ejecuta en primer plano](#run-in-the-foreground), edita tu árbol de trabajo durante tu propio turno, así que `/rewind` restaura sus ediciones como de costumbre.
* **Instrucciones**: la revisión sigue tu `CLAUDE.md`, incluso en una ejecución no interactiva con `-p`. No lee `REVIEW.md`. Ese archivo configura el [servicio Code Review](/docs/es/code-review-customize#use-review-md-for-review-only-rules) administrado en pull requests de GitHub.

<h2 id="how-findings-are-reported">
  Cómo se informan los hallazgos
</h2>

Claude informa los hallazgos como texto en la respuesta en ambas de estas ejecuciones:

* En una sesión de terminal, donde `/code-review` ejecuta la revisión como un [subagente bifurcado](/docs/es/skills#run-skills-in-a-subagent)
* En una ejecución con `-p` con salida de texto o JSON

En una aplicación host que solicita la lista de hallazgos, como la [aplicación de escritorio](/docs/es/desktop#review-your-code), Claude informa los hallazgos de la revisión a través de la [herramienta `ReportFindings`](/docs/es/tools-reference) en su lugar. El informe aparece como una lista de hallazgos, y cada entrada muestra la ubicación del archivo, un resumen de una oración y una etiqueta de categoría como `correctness` cuando el hallazgo tiene una. Una solicitud del host aplica en todos los niveles de esfuerzo y requiere Claude Code v2.1.218 o posterior.

Cuando Claude corrige hallazgos informados más adelante en la sesión, los informa de nuevo. Luego, Claude Code marca cada hallazgo en la lista actualizada como corregido, omitido o sin cambios necesarios.

<h2 id="tune-effort-and-arguments">
  Ajusta el esfuerzo y los argumentos
</h2>

Además de `--fix` y `--comment`, el comando acepta estos flags:

* `--post`: en una revisión en la nube con `ultra` de un pull request de `github.com`, preselecciona publicar los hallazgos finales en el PR en el diálogo de inicio. Consulta [Publicar los hallazgos en el pull request](/docs/es/ultrareview#post-findings-to-the-pull-request). Requiere Claude Code v2.1.227 o posterior.
* `--max-findings <n>`, `--max-findings all` o `--max-findings default`: informa hasta `n` hallazgos, o todos los hallazgos con `all`, en lugar del límite habitual de la revisión. Cuando la revisión informa a través de la herramienta de hallazgos, el límite es 32. Las revisiones posteriores reutilizan el valor que escribiste hasta que pases `--max-findings default`, pero un valor pasado en una ejecución no interactiva con `-p` no se recuerda. Requiere Claude Code v2.1.288 o posterior.

Pasa un [nivel de esfuerzo](/docs/es/model-config#adjust-effort-level) para equilibrar cobertura y confianza. En `low`, la revisión informa los hallazgos de los que tiene más certeza, así que ves menos falsos positivos. Desde `medium` hasta `max`, la revisión amplía la cobertura.

Cuando no escribes un nivel, la revisión reutiliza el último nivel entre `low` y `max` que escribiste, incluso en una sesión anterior. Claude Code muestra un aviso como `Reusing high effort, the level you typed last time`. Estas reglas deciden qué nivel usa una ejecución:

* **Escribir un nivel**: un nivel que escribes, como `/code-review high`, cambia lo que reutilizan las ejecuciones posteriores
* **Ejecuciones no interactivas**: un nivel que pasas en una ejecución no interactiva con `-p` no actualiza el nivel recordado
* **`ultra`**: la revisión no usa ni actualiza el nivel recordado
* **Nunca se escribió un nivel**: la revisión usa el esfuerzo actual de la sesión

Antes de la v2.1.223, un `/code-review` sin nivel siempre usaba el esfuerzo actual de la sesión.

<h3 id="post-findings-to-a-gitlab-merge-request">
  Publicar los hallazgos en un merge request de GitLab
</h3>

Cuando pasas `--comment` para un merge request de GitLab, Claude Code publica los hallazgos a través de la CLI `glab` de GitLab. Requiere Claude Code v2.1.257 o posterior. Cuando `glab` no está instalado, Claude imprime los hallazgos en la terminal en su lugar.

Pasa el merge request como su URL o como una referencia `!123`. Claude Code trata un número o un nombre de rama sin más como un merge request solo cuando el origin del checkout está en `gitlab.com`. En una instancia de GitLab autoadministrada, pasa la URL o la forma `!123`.

<h3 id="text-after-the-effort-level-and-flags">
  Texto después del nivel de esfuerzo y los flags
</h3>

Después del nivel de esfuerzo y los flags, Claude Code lee el resto de la línea como el objetivo de la revisión. El argumento `ultra` cambia esa interpretación:

* **Con `ultra`**: Claude Code lee una sola palabra como una rama base o un número de PR. Un texto más largo que no nombra una rama ni un PR se convierte en [una nota adjunta a la revisión](/docs/es/ultrareview#pass-a-request-in-plain-words). `/code-review ultra check my auth changes` revisa tu rama actual, y Claude relaciona los hallazgos con tu nota.
* **Sin `ultra`**: todo lo que queda es el objetivo de la revisión, incluso cuando empieza con el nombre de otro comando. `/code-review /fix-issue 123` revisa con `/fix-issue 123` como texto del objetivo en lugar de cargar `/fix-issue` como un segundo [skill apilado](/docs/es/skills#pass-arguments-to-skills). Antes de la v2.1.218, un comando apilado después de `/code-review` se expandía como su propio skill.

<h2 id="run-in-the-foreground">
  Ejecutar en primer plano
</h2>

Para que la revisión se ejecute en primer plano, haz una de estas cosas:

* Ejecútala en modo no interactivo, con el flag `-p` o el Agent SDK. Claude Code espera la revisión e incluye los hallazgos en la respuesta, excepto con `ultra`, que [no espera la revisión en la nube](/docs/es/ultrareview#run-ultrareview-non-interactively).
* Establece [`CLAUDE_CODE_DISABLE_BACKGROUND_TASKS`](/docs/es/env-vars) en `1`, lo que también desactiva todas las demás funciones de tareas en segundo plano
* Ejecuta `/code-review` de nuevo mientras una revisión anterior sigue en curso

Antes de la v2.1.218, la revisión se ejecutaba dentro de tu conversación.

<h2 id="let-claude-start-the-review">
  Deja que Claude inicie la revisión
</h2>

Claude puede iniciar `/code-review` por su cuenta, sin que escribas el comando:

* **Cuando lo pides en lenguaje natural**: pídele a Claude que revise tus cambios y puede ejecutar el skill
* **Desde una tarea programada**: una [tarea programada](/docs/es/scheduled-tasks) con `/code-review` como prompt ejecuta la revisión

Una tarea programada nunca inicia la [revisión en la nube](#escalate-to-ultrareview), así que programa `/code-review` sin el argumento `ultra`.

Para evitar que tanto Claude como las tareas programadas inicien la revisión, manteniendo `/code-review` disponible para que lo escribas tú, agrega una entrada [`skillOverrides`](/docs/es/skills#override-skill-visibility-from-settings) a un [archivo de configuración](/docs/es/settings#where-settings-live) como `~/.claude/settings.json`:

```json theme={null}
{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}
```

Antes de la v2.1.246, Claude iniciaba `/code-review` por su cuenta solo donde un feature flag obtenido de Anthropic lo activaba. En [sesiones que no obtienen feature flags](/docs/es/env-vars#features-that-need-feature-flag-fetching), `/code-review` se ejecutaba solo cuando lo escribías, y un `/code-review` programado llegaba a Claude como texto plano.

<h2 id="escalate-to-ultrareview">
  Escalar a ultrareview
</h2>

`/code-review ultra --fix` ejecuta el [ultrareview](/docs/es/ultrareview) más profundo en la nube y luego le pide a Claude que aplique sus hallazgos a tu árbol de trabajo cuando regresen a tu sesión.

Ultrareview usa su propio alcance:

* **Qué compara**: tu rama actual frente a la rama predeterminada del repositorio, además de los cambios sin commit y los cambios preparados (staged) en el árbol de trabajo
* **Archivos sensibles**: para los cambios sin commit en archivos con nombres de credenciales o claves, como los archivos `.env` y `*.tfvars`, Claude Code sigue las reglas para [subir un repositorio local a una sesión en la nube](/docs/es/claude-code-on-the-web#send-local-repositories-without-github)
* **Una base diferente**: pasa un nombre de rama, como `/code-review ultra develop`, para comparar con una base diferente

Cuando el objetivo es un pull request de `github.com`, puedes hacer que Claude [publique los hallazgos finales en el PR](/docs/es/ultrareview#post-findings-to-the-pull-request) como un comentario desde tu cuenta de GitHub. Requiere Claude Code v2.1.227 o posterior.

<Note>
  Ultrareview requiere autenticación con una cuenta de claude.ai. No está disponible en Amazon Bedrock, Agent Platform de Google Cloud ni Microsoft Foundry, ni para organizaciones con Zero Data Retention habilitado o con la [configuración HIPAA](/docs/es/hipaa-setup) aplicada. En estos casos, `/code-review ultra` ejecuta una revisión local en tu sesión en su lugar. Las organizaciones que usan [claves de cifrado administradas por el cliente](https://platform.claude.com/docs/en/manage-claude/cmek) (CMEK) no pueden ejecutar ultrareview. Para revisar tus cambios localmente, ejecuta `/code-review`.
</Note>

Para ejecutar una revisión en la nube desde un script o un job de CI, usa el [subcomando `claude ultrareview`](/docs/es/ultrareview#run-ultrareview-non-interactively), que espera los hallazgos y los imprime en stdout.

<h2 id="change-or-build-on-the-review">
  Modifica la revisión o construye sobre ella
</h2>

`/code-review` es un [skill incluido](/docs/es/skills#bundled-skills): sus instrucciones están integradas en Claude Code, así que no hay ningún archivo `SKILL.md` en disco que abrir o editar. Para darle a cada revisión reglas del proyecto que seguir, agrégalas a tu `CLAUDE.md`. Para ir más allá, empieza desde una de estas páginas:

* **Reemplazar el comando**: un skill de proyecto o personal llamado `code-review` se ejecuta en lugar del incluido, y el alias `/review` sigue ejecutando la revisión incluida. Consulta [Resolver skills que comparten nombre](/docs/es/skills#resolve-skills-that-share-a-name).
* **Crear tu propio revisor**: escribe un [subagente](/docs/es/sub-agents) revisor o un [skill](/docs/es/skills) de revisión
* **Usar un comando cercano**: [`/simplify`](/docs/es/commands) revisa solo para limpieza y aplica sus correcciones, y [`/verify`](/docs/es/commands) ejecuta tu aplicación para confirmar que un cambio funciona

El comando se llamaba `/simplify` antes de la v2.1.147, cuando aplicaba correcciones de forma predeterminada. Si tenías scripts con `/simplify` para encontrar bugs, cámbialos a `/code-review --fix`.

<h2 id="related-resources">
  Recursos relacionados
</h2>

* [Code Review](/docs/es/code-review): el servicio administrado que revisa cada pull request en GitHub para tu organización
* [Ultrareview](/docs/es/ultrareview): configuración, límites y costo de la revisión en la nube más profunda
* [Comandos](/docs/es/commands): la referencia de una línea para `/code-review`, `/review`, `/simplify` y `/verify`
* [Skills](/docs/es/skills): cómo funcionan los skills incluidos y cómo escribir los tuyos