Claude Code Review ya está disponible de forma general: sus reglas de REVIEW.md solo cuentan una vez fusionadas, y la protección de rama decide el resto (2026)

El anuncio de disponibilidad general describe tres cambios. Las revisiones son más rápidas que durante la vista previa. Los hallazgos se redactan para ser más cortos, indicando el problema, qué lo desencadena y la solución. Y los administradores ahora eligen un nivel de revisión por repositorio: "Los administradores eligen Quick, Standard (predeterminado) o Deep para cada repositorio, de modo que las bases de código rutinarias reciben una revisión rápida y las más críticas obtienen una revisión profunda".

La forma del producto es la misma: varios agentes leen cada cambio, un paso de verificación filtra sus hallazgos y los resultados llegan como comentarios en línea más una ejecución de comprobación (check run) llamada Claude Code Review. Dos propiedades importan antes que cualquier otra cosa:

• No fusiona ni bloquea. La documentación dice: "Una revisión nunca aprueba ni bloquea el pull request, por lo que la decisión de fusionar sigue siendo de tu equipo".
• Lee, no ejecuta. Una revisión "funciona leyendo el diff y el código circundante, sin compilar ni ejecutar tu código". Dentro de una revisión, "el acceso a tu repositorio es de solo lectura, y una revisión no realiza commits".

Por lo tanto, el juicio del revisor se basa en lo que lee, incluidos tus archivos de instrucciones.

Code Review se guía por dos tipos de archivos en tu repositorio.

CLAUDE.md es el archivo de instrucciones del proyecto que Claude Code ya utiliza. Anthropic lo describe como "instrucciones del proyecto que Claude Code lee para cada tarea, incluidas las revisiones. Code Review las lee como contexto del proyecto y marca los cambios que las violen". La revisión no lee cada CLAUDE.md en el repositorio. "Una revisión lee el CLAUDE.md en la raíz de tu repositorio y los archivos CLAUDE.md en los directorios padres de cada archivo modificado. El CLAUDE.md de un subdirectorio se lee cuando el pull request modifica un archivo bajo esa ruta".

REVIEW.md es específico de Code Review. Son "instrucciones solo para revisiones. Úsalo para indicar qué quiere tu equipo que se marque, con qué severidad y qué omitir". Puedes colocar uno en la raíz del repositorio y agregar más en subdirectorios para añadir comprobaciones para los cambios bajo esas rutas. Su contenido llega a cada etapa de la revisión: "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 la guía de revisión predeterminada de Code Review. El paso que escribe la revisión final lo consulta antes de definir la severidad y escribir el resumen".

La división que recomienda Anthropic es simple: "Mantén REVIEW.md para las instrucciones que cambian el comportamiento de la revisión, y deja el contexto general del proyecto en CLAUDE.md". Por defecto, Code Review se centra en la corrección, es decir, errores que romperían la producción en lugar de formato o cobertura de pruebas. REVIEW.md es cómo mueves esa línea para tu repositorio: redefine qué cuenta como Importante, limita los comentarios menores (nits), enumera las rutas a omitir, agrega comprobaciones que le importen a tu equipo o requiere un archivo y una línea como evidencia para ciertos tipos de hallazgos.

En una publicación sobre cómo el equipo de Claude Code realiza la revisión de código, Anthropic escribe que "CLAUDE.md le dice a Claude qué es el proyecto: el stack, las convenciones, los objetivos y los no-objetivos. Cada revisión lo carga, por lo que en una base de código grande lo mantenemos corto y apuntamos a otros documentos desde allí". Y "REVIEW.md, escrito por los propietarios del código, le dice al revisor qué importa en su parte del código. Comprobamos por separado si el revisor realmente lo sigue".

Anthropic no asume que el archivo se siga. Las reglas a continuación explican por qué una regla que escribiste podría no estar en vigor.

La documentación es inequívoca: "Code Review lee REVIEW.md de la rama base del pull request o de la rama predeterminada, nunca de los propios cambios del pull request. Para cambiar el comportamiento de la revisión, fusiona primero el cambio de REVIEW.md".

En la práctica, esto afecta a un flujo de trabajo natural. Un desarrollador nota que el revisor marca archivos generados, agrega una regla de omisión a REVIEW.md en el mismo pull request que activó los comentarios y hace un push. La siguiente revisión se ejecuta contra la copia de REVIEW.md en la rama base o predeterminada, que aún no tiene la nueva regla. Los comentarios siguen llegando hasta que se fusiona el cambio.

Del mismo modo, el pull request que introduce por primera vez REVIEW.md se revisa sin él.

La documentación establece la regla sin dar una razón. Su efecto es que las propias ediciones de un pull request a REVIEW.md no pueden reducir la severidad de sus hallazgos ni excluir los archivos que modifica. Esa decisión queda en manos de quien controle las fusiones a la rama de la que lee la revisión.

La consecuencia práctica: trata los cambios de REVIEW.md como sus propios pequeños pull requests, fusionados antes del trabajo al que deben afectar.

Fusionar REVIEW.md no es el final de la historia. Code Review comprueba si la rama de la que lee está protegida, y la respuesta cambia lo que lee y lo que respeta.

La guía de Anthropic es "Mantener REVIEW.md en tu rama predeterminada y proteger esa rama". Cuando la revisión lee la copia en una rama predeterminada protegida, respeta tres tipos de instrucciones del archivo raíz:

• Reducir la severidad de un hallazgo
• Excluir rutas, archivos o clases de problemas
• Limitar los comentarios menores (nits)

Esas son tres de los cinco tipos de instrucciones que la documentación sugiere escribir en primer lugar. Un REVIEW.md que dice ignorar archivos de bloqueo (lockfiles) y mantener los nits al mínimo depende de la protección de rama para tener efecto.

La documentación presenta cuatro situaciones:

Dos filas merecen atención. En la tercera, los archivos REVIEW.md de los subdirectorios no se leen en absoluto, por lo que las comprobaciones por directorio quedan fuera. En la cuarta, no se lee ningún REVIEW.md. La documentación señala que este caso "incluye una rama predeterminada no protegida con una rama base que tiene solo una regla clásica".

Lo que cuenta como protección también es específico. Para la rama predeterminada, Code Review acepta "una regla de protección de rama clásica o un conjunto de reglas (ruleset)". Para cualquier otra rama, es "solo un conjunto de reglas". Y no cualquier conjunto de reglas califica: "Un conjunto de reglas cuenta cuando restringe las actualizaciones o requiere pull requests con al menos una aprobación. Si requiere pull requests, también debe descartar esa aprobación ante un nuevo push o requerir que la aprobación se realice después del último push".

La ejecución de la comprobación (check run) te indica cuándo está ocurriendo esto. Un mensaje dice: "Esta revisión aplicó las instrucciones de revisión del repositorio (REVIEW.md) de su rama predeterminada, que no está protegida contra pushes directos". Eso significa que solo se leyó el archivo raíz. Otro dice que las instrucciones "no se aplicaron a esta revisión: no se pudo confirmar la protección de la rama", lo que significa que no se aplicó ninguna.

Code Review tiene un hermano que se ejecuta en tu propia sesión. La documentación señala la diferencia directamente: "El servicio Code Review y el comando local /code-review son dos herramientas independientes y leen archivos diferentes".

El servicio lee tanto CLAUDE.md como REVIEW.md. El comando local sigue tu CLAUDE.md, "incluso en una ejecución no interactiva con -p. No lee REVIEW.md".

Esto tiene una consecuencia en cómo escribes las reglas. Una comprobación que viva solo en REVIEW.md aparecerá en las revisiones de los pull requests y no cuando un desarrollador ejecute /code-review antes de abrir el pull request. El consejo de Anthropic: "Coloca la guía que deseas que se aplique en ambos lugares en CLAUDE.md, y mantén REVIEW.md para las reglas específicas de la revisión de pull requests".

Los desarrolladores que revisen localmente antes de hacer push verán a dos revisores trabajando a partir de instrucciones que se superponen pero son diferentes.

Asumir que un nuevo REVIEW.md funciona tan pronto como se sube (push). Funciona una vez que se fusiona con la rama de la que lee Code Review, y por completo solo cuando esa rama está protegida. Nuestra guía sobre por qué los agentes ignoran tus archivos de instrucciones cubre el mismo tipo de brecha en las sesiones de programación.

Asumir que las respuestas enseñan al revisor. Responder a un hallazgo es una conversación con la próxima revisión de ese pull request, no una regla duradera. "Responder por sí solo no descarta un hallazgo". La siguiente revisión "lee las respuestas de sus hallazgos anteriores y puede resolver el hilo o publicar una respuesta de seguimiento". El consejo de la documentación para un hallazgo que sigue ocurriendo es "pedirle a un mantenedor que agregue una regla a REVIEW.md".

Asumir que CLAUDE.md es solo para sesiones de programación. Code Review lo lee como contexto del proyecto y marca las violaciones. El equipo de Anthropic señala que su propio revisor "también marca el código que rompe una convención en él, y los cambios que hacen que una línea en él quede desactualizada". Una vez que un revisor lee CLAUDE.md, mantenerlo al día es importante para las revisiones, no solo para las sesiones. Nuestra guía para conciliar capas de CLAUDE.md en conflicto cubre cómo encontrarlas y solucionarlas.

Paso 1: Proteger la rama predeterminada y confirmar qué copia se lee

Comprueba la protección de tu rama con la tabla anterior. Dale a la rama predeterminada una regla clásica o un conjunto de reglas. Si los pull requests se dirigen a otras ramas de larga duración, esas ramas necesitan un conjunto de reglas para que sus propias copias de REVIEW.md cuenten.

Luego, abre un pequeño pull request de prueba y lee la ejecución de comprobación (check run). Si dice que las instrucciones provienen de una rama no protegida, o que no se aplicaron, soluciona eso primero.

Paso 2: Dividir tus reglas entre CLAUDE.md y REVIEW.md

Revisa las reglas que deseas aplicar y clasifícalas:

• Las reglas sobre el proyecto en sí van en CLAUDE.md: convenciones, límites de arquitectura, los no-objetivos hacia los que un cambio no debería desviarse. Estas se aplican en las sesiones de programación, en las revisiones locales y en las revisiones de pull requests.
• Las reglas sobre la revisión van en REVIEW.md: qué cuenta como Importante en este repositorio, cuántos nits publicar, qué rutas omitir, qué comprobaciones ejecutar siempre.
• Las reglas para un área del código van en un CLAUDE.md o REVIEW.md de subdirectorio. Los archivos REVIEW.md de subdirectorios dependen de la protección de rama.

Fusiona el cambio de REVIEW.md por sí solo. Si estás escribiendo reglas de CLAUDE.md por primera vez, nuestra guía para hacer que Claude se adhiera a tu estilo de programación cubre cómo redactar las convenciones para que se sigan.

Paso 3: Convertir los hallazgos repetidos en reglas fusionadas y conservar los motivos

El propio proceso de Anthropic es el modelo aquí. "Cuando el revisor automatizado sigue marcando lo mismo, lo solucionamos en la fuente", escribe el equipo. Su despliegue recomendado es agregar un revisor de IA a un repositorio, "ajustar REVIEW.md durante unas semanas y luego ampliarlo". Y cuando una revisión pasa por alto algo, "nos preguntamos qué no tenía el modelo delante y ponemos la solución en un CLAUDE.md, una habilidad o una nueva comprobación".

Cada una de esas soluciones es una decisión: por qué se excluye una ruta, por qué una clase de hallazgo es Importante aquí y un Nit en otro lugar, qué incidente llevó a una comprobación. La regla va en el archivo. También vale la pena conservar el motivo, porque la próxima persona que edite REVIEW.md lo necesitará para saber si la regla aún se aplica. Nuestra guía sobre cómo Claude Code olvida tus correcciones cubre el mismo patrón para las sesiones de programación: las correcciones que más importan pertenecen a un archivo que todo el equipo pueda leer.

REVIEW.md contiene la regla. El historial detrás de ella, como el incidente, el debate y la alternativa que rechazaste, vive dondequiera que haya ocurrido esa discusión: un hilo de pull request, un chat, la memoria de una persona. MemoryLake es una capa de memoria para mantener ese tipo de registro de decisiones en una lista que tú mantienes, disponible para Claude Code y los demás asistentes que conectes mientras escribes el código que una revisión leerá más tarde.

Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de los archivos CLAUDE.md o REVIEW.md de tu repositorio, tus pull requests, los hallazgos de Code Review o el almacenamiento de ningún proveedor. El servicio Code Review lee solo lo que está en tu repositorio, por lo que las reglas que aplica siguen perteneciendo a esos archivos. Consulta la política de tu organización antes de almacenar detalles del proyecto fuera del repositorio.

Paso 1: Crear una clave de API

Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake y es independiente de tus cuentas de Anthropic y GitHub.

Paso 2: Subir tus primeras memorias

Comienza con los motivos detrás de tus reglas de revisión: por qué se omite una ruta, por qué una clase de hallazgo es Importante en este repositorio, qué incidente llevó a una comprobación. Una decisión por entrada, fechada, con un puntero a la regla que explica.

Paso 3: Conectar tu IA y agentes

Conecta Claude Code y cualquier otro asistente que utilices. El razonamiento detrás de tus reglas estará disponible mientras se escribe el código, antes de que un pull request llegue al revisor.

El primer cambio es menos sorpresas en la ejecución de la comprobación (check run). Una vez que se confirma la protección de la rama, las exclusiones y los límites de nits que escribiste surten efecto. El segundo es la consistencia: las reglas que deberían aplicarse en todas partes se encuentran en CLAUDE.md, por lo que un /code-review local y la revisión del pull request esperan las mismas cosas. El tercero es una configuración que mejora a propósito, con hallazgos recurrentes convertidos en reglas cuyos motivos quedan registrados por escrito. Nuestra mirada a lo que realmente leen los agentes de programación cubre por qué ese contexto escrito importa en todas las herramientas.

Fusiona los cambios de REVIEW.md por separado. Un pull request se revisa con la copia de la rama base.

Protege la rama predeterminada. Los cambios de severidad, las exclusiones y los límites de nits dependen de ello.

Lee los mensajes de la ejecución de comprobación (check run). Indican cuándo se leyó solo el archivo raíz, o ninguno.

Coloca las reglas compartidas en CLAUDE.md. El comando local no lee REVIEW.md.

Mantén ambos archivos cortos. El propio veredicto de Anthropic sobre los archivos de revisión: "Los buenos son cortos".

La disponibilidad general de Code Review convierte la revisión por IA en cada pull request en una opción predeterminada para las organizaciones Team y Enterprise. Lo que revisa sigue dependiendo del equipo: REVIEW.md se lee desde la rama base o predeterminada, nunca desde los propios cambios del pull request; la protección de rama decide si los archivos de los subdirectorios cuentan y si se respetan los cambios de severidad, las exclusiones y los límites de nits; y cuando no se puede confirmar la protección, no se lee ningún REVIEW.md. Protege la rama, divide las reglas del proyecto de las reglas de revisión y convierte los hallazgos repetidos en reglas fusionadas registrando sus motivos.