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

# Personalizar Code Review

> Ajusta lo que Code Review señala en tus pull requests con REVIEW.md y CLAUDE.md: recalibra la severidad, omite rutas, agrega comprobaciones y consulta qué copia se aplica.

Puedes cambiar lo que [Code Review](/docs/es/code-review) señala en tu repositorio confirmando instrucciones en él. Así es como reduces el volumen de nits, detienes los comentarios sobre archivos generados o agregas una regla que le importa a tu equipo. Colócalas en uno de estos dos archivos:

* **`CLAUDE.md`**: [instrucciones del proyecto](/docs/es/memory) que Claude Code lee en cada tarea, incluidas las revisiones. Code Review las lee como contexto del proyecto y señala los cambios que las infringen.
* **`REVIEW.md`**: instrucciones exclusivas para las revisiones. Úsalo para indicar qué quiere tu equipo que se señale, con qué severidad y qué omitir.

Agrega `REVIEW.md` en la raíz de tu repositorio y fusiónalo. Luego [protege tu rama predeterminada](#which-branch-review-md-is-read-from).

<Note>
  Para cambiar qué tan exhaustivas son las revisiones o cuándo se ejecutan, pídele a un Owner que cambie el [nivel de revisión](/docs/es/code-review-setup#set-the-default-review-level) o el [ajuste **Review runs**](/docs/es/code-review-setup#set-when-reviews-run).
</Note>

<h2 id="use-claude-md-for-project-wide-rules">
  Usa CLAUDE.md para reglas de todo el proyecto
</h2>

Code Review lee los archivos `CLAUDE.md` de tu repositorio como contexto del proyecto. Un cambio que infringe una de sus reglas se convierte en un hallazgo con el [nivel de severidad](/docs/es/code-review-pull-requests#severity-levels) que corresponda al problema.

Una revisión lee el `CLAUDE.md` de la raíz de tu repositorio y los archivos `CLAUDE.md` de los directorios padre de cada archivo modificado. El `CLAUDE.md` de un subdirectorio se lee cuando el pull request modifica un archivo bajo esa ruta.

<h2 id="use-review-md-for-review-only-rules">
  Usa REVIEW\.md para reglas exclusivas de revisión
</h2>

`REVIEW.md` es un archivo en la raíz de tu repositorio que adapta Code Review a tu repositorio. También puedes agregar un `REVIEW.md` en un subdirectorio para añadir comprobaciones a los cambios bajo esa ruta, además del archivo raíz.

Los agentes que encuentran problemas y los agentes que los verifican reciben su contenido como las instrucciones de revisión de tu repositorio, junto con las pautas de revisión predeterminadas de Code Review. El paso que redacta la revisión final lo consulta antes de definir la severidad y escribir el resumen.

Este diseño de ejemplo tiene un archivo raíz y un archivo en un subdirectorio:

```text theme={null}
your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/
```

Antes de depender de un archivo en un subdirectorio, protege tu rama predeterminada y consulta [qué lee una revisión según la configuración de tus ramas](#what-a-review-reads-for-each-branch-setup).

<Note>
  El servicio Code Review y el [comando local `/code-review`](/docs/es/code-review-local) son dos herramientas distintas y leen archivos diferentes. El servicio lee tanto `CLAUDE.md` como `REVIEW.md`. El comando `/code-review`, que ejecutas dentro de una sesión de Claude Code en tu propia máquina, lee tus archivos `CLAUDE.md` pero no `REVIEW.md`. Coloca en `CLAUDE.md` las pautas que quieras aplicar en ambos lugares y reserva `REVIEW.md` para reglas específicas de la revisión de pull requests.
</Note>

<h3 id="example-review-md">
  Ejemplo de REVIEW\.md
</h3>

Este `REVIEW.md` recalibra la severidad para un servicio de backend, limita los nits, omite los archivos generados y agrega comprobaciones específicas del repositorio.

```markdown theme={null}
# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant
```

<h3 id="choose-what-to-write-in-review-md">
  Elige qué escribir en REVIEW\.md
</h3>

`REVIEW.md` es markdown de formato libre que cambia lo que una revisión encuentra y reporta. No cambia el formato de la revisión. Busca el problema que estás viendo y luego agrega una instrucción como la que se muestra. El [ejemplo](#example-review-md) usa las cuatro primeras.

* **Se marcan como Important las cosas equivocadas**: redefine qué significa 🔴 Important para tu repositorio. La calibración predeterminada apunta a código de producción, y un repositorio de documentación, un repositorio de configuración o un prototipo podrían necesitar una definición mucho más estrecha. Indica qué clases de hallazgos son Important y cuáles son, como mucho, Nit. También puedes escalar, por ejemplo, tratando cualquier infracción de `CLAUDE.md` como Important.
* **Demasiados nits**: limita cuántos comentarios 🟡 Nit publica una sola revisión. Un límite como "reporta como máximo cinco nits" mantiene las revisiones accionables.
* **Comentarios sobre archivos generados o sobre lo que CI ya comprueba**: enumera las rutas y categorías de hallazgos en las que Claude debe omitir hallazgos. Los candidatos habituales son el código generado, los lockfiles y las dependencias incluidas en el repositorio (vendored), junto con cualquier cosa que tu CI ya aplique, como el linting o la revisión ortográfica. Para rutas que merecen algo de revisión pero no un escrutinio completo, establece un umbral más alto: "en `scripts/`, reporta solo si es casi seguro y grave".
* **No se comprueba una regla del equipo**: agrega las reglas que quieras que se señalen en cada pull request, como "las nuevas rutas de API deben tener una prueba de integración".
* **Hallazgos que resultan ser incorrectos**: exige evidencia antes de que se publique una clase de hallazgo. Por ejemplo, "las afirmaciones sobre el comportamiento necesitan una cita `file:line` en el código fuente, no una inferencia a partir de los nombres" reduce los falsos positivos que, de lo contrario, le costarían al autor una ida y vuelta.

Algunas de estas instrucciones [necesitan el archivo raíz en una rama predeterminada protegida](#which-branch-review-md-is-read-from).

Limita `REVIEW.md` a instrucciones que cambien el comportamiento de la revisión y deja el contexto general del proyecto en `CLAUDE.md`.

<h3 id="which-branch-review-md-is-read-from">
  Desde qué rama se lee REVIEW\.md
</h3>

Code Review lee `REVIEW.md` desde la rama base del pull request o desde la rama predeterminada, nunca desde los propios cambios del pull request. Para cambiar el comportamiento de la revisión, fusiona primero el cambio en `REVIEW.md`.

Mantén `REVIEW.md` en tu rama predeterminada y protege esa rama. Cuando una revisión lee la copia de una rama predeterminada protegida, la primera fila de la tabla siguiente, respeta estas instrucciones del archivo raíz:

* Reducir la severidad de un hallazgo
* Excluir rutas, archivos o clases de problemas
* Limitar los comentarios de tipo nit

<h4 id="what-counts-as-branch-protection">
  Qué cuenta como protección de rama
</h4>

Code Review considera protección los siguientes ajustes:

* **Rama predeterminada**: una regla clásica de protección de rama o un ruleset
* **Cualquier otra rama**: solo un ruleset

Un ruleset cuenta cuando restringe las actualizaciones o exige pull requests con al menos una aprobación. Si exige pull requests, también debe descartar esa aprobación ante un nuevo push o exigir que la aprobación llegue después del último push.

<h4 id="what-a-review-reads-for-each-branch-setup">
  Qué lee una revisión según la configuración de ramas
</h4>

Busca la situación de tu repositorio en la primera columna de la tabla siguiente.

| Protección de rama | Copia leída | Archivos leídos |
| :- | :- | :- |
| La rama predeterminada está protegida y el pull request apunta a ella o a una rama que ningún ruleset protege | Rama predeterminada | Archivos raíz y de subdirectorios |
| El pull request apunta a otra rama que un ruleset protege | Esa rama base | Archivos raíz y de subdirectorios |
| La rama predeterminada no está protegida y la rama base no tiene ninguna regla de protección de ningún tipo | Rama predeterminada | Archivo raíz |
| Code Review no puede confirmar la configuración de protección. Esto incluye una rama predeterminada sin protección con una rama base que solo tiene una regla clásica | Ninguna | Ninguno |

Si la ejecución de comprobación menciona `REVIEW.md`, consulta [The check run mentions REVIEW.md](/docs/es/code-review-troubleshooting#the-check-run-mentions-review-md).

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

* [Code Review](/docs/es/code-review): qué es el servicio y cómo se ejecuta una revisión
* [Leer y solicitar revisiones en un pull request](/docs/es/code-review-pull-requests#severity-levels): qué significa cada nivel de severidad y cómo aparecen los hallazgos
* [Configurar Code Review](/docs/es/code-review-setup): el nivel de revisión y cuándo se ejecutan las revisiones, que establece un Owner
* [Revisar localmente con `/code-review`](/docs/es/code-review-local): el comando `/code-review`, sus argumentos y los niveles de esfuerzo
* [Memoria](/docs/es/memory): cómo funcionan los archivos `CLAUDE.md` en Claude Code