Revisar cambios de código por fases con subagentes en paralelo

A quién le sirve. Programadores y equipos que quieren una segunda revisión automática de sus pull requests antes de que las vea otra persona.

Qué hicieron

El comando /adamsreview:review lanza hasta siete subagentes en paralelo con enfoques distintos (corrección, seguridad, experiencia de uso y otros) sobre una rama o un pull request. Sus hallazgos pasan por eliminación de duplicados, una validación barata y luego profunda, y una pasada transversal opcional con Opus. Con --ensemble añade una pasada de Codex y recoge los comentarios de bots del pull request. /adamsreview:fix ejecuta después subagentes de corrección en paralelo, revisa de nuevo con Opus, revierte lo que empeora y guarda el resto. /adamsreview:walkthrough deja que una persona decida los hallazgos dudosos.

Cómo salió

El autor cuenta, de forma anecdótica sobre sus propios pull requests, que detecta muchos más errores reales que /review, /ultrareview, CodeRabbit, Greptile y la revisión de Codex, con menos falsos positivos. No da cifras medidas.

Conviene saber

--ensemble gasta más tokens y necesita el complemento de Codex para Claude Code. Funciona con una suscripción normal de Claude Code (se recomienda Max), no con créditos de uso extra como /ultrareview.

Qué necesitas

• Claude Code con una suscripción normal (se recomienda Max)
• El complemento adamsreview, de código abierto
• Un repositorio, que es el código de tu proyecto, con un pull request o una rama para revisar
• El complemento de Codex para Claude Code, si quieres la opción ensemble
• Un programador que decida sobre los hallazgos dudosos

Cómo hacerlo tú, paso a paso

1. Instala Claude Code y el complemento adamsreview, que añade comandos nuevos.
2. Abre tu repositorio en la rama o el pull request que quieres revisar. Un pull request es una propuesta de cambio de código, y una rama, una versión paralela del proyecto.
3. Lanza el comando de revisión sobre esa rama o pull request. Arrancará varios subagentes con enfoques distintos, como corrección, seguridad o experiencia de uso.
4. Lee los hallazgos ordenados. Los dudosos los decides tú con el comando de recorrido.
5. Si quieres, ejecuta el comando de corrección, que arregla en paralelo, vuelve a revisar y revierte lo que empeore.
6. Para una segunda opinión, añade la opción ensemble con el complemento de Codex. Gasta más cuota de uso.

Revisa por fases el pull request que está en [dirección del pull request o nombre de la rama]: usa subagentes distintos para comprobar corrección, seguridad, pruebas y estilo, y haz después una pasada de validación que descarte los hallazgos que no puedas respaldar con una línea concreta de código. Termina con una lista ordenada de problemas, cada uno con archivo, línea y una corrección sugerida. No publiques comentarios en el pull request: solo enséñame la lista.

Consejos

• Empieza con una rama pequeña para ver el gasto antes de revisar una grande.
• Comprueba cada hallazgo en la línea de código a la que apunta. Son orientativos, no una sentencia.
• La comparación con otras herramientas es una impresión del autor sobre sus propios cambios, no un estudio.

Preguntas frecuentes

Fuentes

• adamjgmiller/adamsreview en GitHub ↗
• La conversación en Hacker News, 11 de mayo de 2026 ↗

En el directorio desde el 3 de octubre de 2026.