Deja de buscar herramientas: los tres comandos que revisan tu código ya vienen instalados

La escena se repite todas las semanas: alguien abre un marketplace de plugins, busca «code review», guarda tres repos de GitHub, lee una lista de skills de la comunidad y termina copiando un prompt de mil palabras a un archivo nuevo — todo para que algo le revise el código antes de subirlo. Y mientras tanto, en la misma terminal donde está haciendo la búsqueda, ya hay tres comandos que hacen exactamente eso. No hay que instalarlos, no salen de ningún marketplace y no piden una API key aparte: vienen dentro de Claude Code.

Los tres son nativos. /verify y /code-review llegan como bundled skills —las skills que Claude Code trae de fábrica—, y /security-review es un comando nativo del propio Claude Code. Eso significa que no dependen de que alguien mantenga un repo de terceros, no hay que registrar nada y no hay un paso de configuración previo: si tienes Claude Code abierto, escribes la diagonal, el nombre del comando y ya está corriendo. La única condición real es tener una versión reciente — /verify pide v2.1.145 o más — y eso se resuelve actualizando, no instalando.

Vale la pena decirlo directo porque es la parte que más gente se pierde: no son tres versiones de lo mismo. Cada uno mira una cosa distinta y responde una pregunta distinta. Uno comprueba que tu cambio de verdad funciona corriéndolo, otro busca defectos leyendo el diff de tu rama, y el tercero hace una pasada de seguridad sobre esos mismos cambios. Corren separados, se pueden encadenar y no se pisan entre ellos.

Lo que sigue es un comando por sección —qué revisa de verdad, sus trampas y cómo sacarle más—, después la rutina de los tres juntos antes de hacer push, el modo ultra para cuando la revisión local no alcanza, los comandos vecinos que todo el mundo confunde con estos, y lo que ninguno de los tres puede hacer por ti.

Este es el comando que más gente entiende al revés. Al leer «verify» todo el mundo piensa «va a correr mis tests otra vez», y no: /verify construye tu aplicación, la arranca y comprueba que el cambio que acabas de hacer hace lo que debe hacer. La documentación lo dice sin rodeos: no se conforma con que pasen los tests ni con que el type check esté verde. Esas dos señales son necesarias, pero no prueban nada sobre tu cambio.

Piénsalo así: los tests te dicen que no rompiste lo que alguien ya se tomó la molestia de escribir como prueba. El type check te dice que los tipos encajan. Ninguno de los dos entra a la pantalla, toca el botón y mira qué pasó. Ese hueco entre «compila» y «funciona» es donde vive la mayoría de los bugs que llegan a producción, y es exactamente el hueco que /verify tapa.

Verifica este cambio corriendo la app de verdad, no solo los tests.

Qué cambié: [EL CAMBIO EN UNA FRASE]
Dónde se comprueba: [PANTALLA, RUTA, ENDPOINT O COMANDO EXACTO]
Cómo se llega hasta ahí: [PASOS: login, navegación, flag, estado previo]
Dato de prueba: [QUÉ ESCRIBO O QUÉ MANDO]
Qué debo ver si funciona: [RESULTADO ESPERADO, CONCRETO Y OBSERVABLE]
Cómo se vería si falló: [EL SÍNTOMA DEL BUG]

Arranca la app como corresponde a este proyecto, llega hasta esa superficie,
ejecuta el caso con ese dato y dime qué observaste tal cual: lo que apareció
en pantalla o en la respuesta, y si coincide o no con lo esperado.

Si no logras llegar hasta ahí, dime en qué paso te trabaste en lugar de dar
el cambio por bueno. No cuentes como verificación que los tests pasen.

Al cerrar, resume en tres líneas: qué corriste, qué observaste y el veredicto.

Regla de bolsillo para el resto de la guía: /verify contesta «¿esto hace lo que debe?». Los dos comandos que siguen contestan otras dos preguntas distintas — «¿está bien hecho?» y «¿es seguro?» — y ninguno de los tres reemplaza a los otros dos.

Este es el comando que más vas a usar de los tres. Sin argumentos, revisa exactamente lo que traes en curso: todo lo que cambiaste en tu rama y que todavía no está en la rama remota de la que saliste, más lo que tengas a medias sin guardar en un commit. Dicho sin jerga: revisa tu trabajo de hoy, no el repositorio entero ni el historial de los últimos tres años. Por eso da resultados útiles en vez de una lista infinita de cosas que nadie va a arreglar.

Y no es un «vale, se ve bien». Busca bugs de lógica, casos borde que no cubriste, condiciones de carrera, manejo de errores incompleto y suposiciones que tu código hace sin decirlo. Lo que hace un colega senior cuando te abre el pull request y se toma el trabajo en serio, salvo que este está disponible a las once de la noche y no se cansa al tercer archivo.

Acabas de darme los hallazgos de la revisión. Antes de tocar código, ayúdame a decidir qué arreglar y qué no.

Para cada hallazgo dime:
1. Si es un bug real que se puede disparar hoy, un riesgo teórico, o una cuestión de estilo.
2. Qué tendría que pasar exactamente para que le explote a un usuario (entradas concretas, no descripciones vagas).
3. Cuánto trabajo es arreglarlo: minutos, media hora, o algo que merece su propia tarea.

Después ordénalos en tres grupos:
- ARREGLAR AHORA: bloquean el merge.
- ANOTAR: reales pero no urgentes, van a la lista de pendientes.
- DESCARTAR: falsos positivos o cosas que en este proyecto son a propósito. Explica por qué en una línea.

Reglas: no arregles nada todavía. Si un hallazgo choca con una regla que está escrita en mi CLAUDE.md, dímelo explícitamente en vez de asumir cuál gana.

Con esto ya sabes usar el comando completo: escribes /code-review pelón para el día a día, le subes el nivel cuando el cambio da miedo, le pasas un target cuando quieres apuntar a algo concreto, y guardas --fix para cuando ya leíste la lista. Falta la tercera pata, que es la que revisa lo que un revisor humano cansado deja pasar: la seguridad.

Es el tercero de los tres comandos que ya traes puestos, y el más fácil de explicar: es una pasada de seguridad bajo demanda sobre los cambios de tu rama actual. Lo escribes, Claude lee lo que tocaste y te devuelve una lista de hallazgos con el archivo, la línea y por qué eso es un riesgo. No hay que instalar un escáner, ni conectar un servicio, ni configurar reglas: el mismo modelo con el que llevas trabajando cambia de sombrero y relee tu diff buscando cómo romperlo.

La diferencia con /code-review es de intención, no de potencia. /code-review busca lo que está mal en general —bugs, casos borde, lógica floja— y la seguridad es una parte de eso. /security-review entra con una sola pregunta en la cabeza: si alguien con malas intenciones tocara esta ruta, ¿qué podría sacar? Por eso encuentra cosas que una revisión general deja pasar: código que funciona perfecto y aun así deja una puerta abierta. Corre los dos, no elijas.

Quiero una auditoría de seguridad de TODO este repositorio, no solo de mis cambios recientes.

Contexto del proyecto:
- Qué hace: [DESCRIBE TU APP EN UNA FRASE]
- Quién la usa: [PÚBLICO ABIERTO / USUARIOS CON CUENTA / EQUIPO INTERNO]
- Lo más sensible que maneja: [DATOS PERSONALES, PAGOS, ARCHIVOS, ETC.]

Revisa el proyecto por estas familias, en este orden:
1. Secretos y credenciales dentro del código o en archivos versionados.
2. Autenticación y autorización: rutas y endpoints donde se verifica la sesión pero no se verifica que el recurso le pertenezca a quien lo pide.
3. Entradas del usuario que llegan a la base de datos, al sistema de archivos, al shell o al HTML sin sanitizar.
4. Datos sensibles en logs, en mensajes de error o en respuestas de API que devuelven más campos de los necesarios.
5. Dependencias con versiones viejas o abandonadas en las partes que tocan datos de usuario.

Cómo quiero el resultado:
- Empieza por un resumen de máximo 10 líneas con el estado general.
- Después la lista de hallazgos ordenada de más grave a menos, y para cada uno: archivo y línea, qué podría hacer un atacante en concreto, y el arreglo puntual.
- Marca aparte lo que sea sospecha sin confirmar, para no mezclarlo con lo confirmado.
- No arregles nada todavía. Primero quiero leer la lista completa y decidir el orden.

La forma sana de pensarlo: el comando es tu revisión antes de hacer push, la Action es la que revisa a todo el equipo cuando tú no estás viendo. Si trabajas solo, con el comando te alcanza. Si hay más de una persona empujando código al mismo repositorio, la Action deja de ser opcional — porque el cambio riesgoso casi nunca es el tuyo, es el que se mergeó un viernes mientras nadie miraba.

Hasta aquí la guía fue referencia: qué hace cada comando por separado. Esta sección es la parte que de verdad cambia tu semana, porque convierte los tres en una sola secuencia que corres siempre igual. La idea no es acordarte de revisar cuando el cambio se ve peligroso —ahí ya llegaste tarde y además el juicio de «esto se ve peligroso» es justo el que falla—. La idea es que la secuencia salga sola, en todo cambio, aunque sean tres líneas.

Son cuatro pasos y cada uno tiene su comando copiable. Los tres primeros los invocas tú desde la misma sesión donde trabajaste, así que no hay que cambiar de ventana ni de herramienta; el último cierra con la pasada de seguridad. Corre en el mismo orden siempre: cuando el orden es fijo, dejas de decidir y empiezas a ejecutar, que es de lo que se trata un hábito.

Voy a subir estos cambios. Antes de que lo haga, hazme la pasada completa de revisión sobre el diff de mi rama y lo que tengo sin commitear. En este orden y sin saltarte pasos.

1. EL CAMBIO. Enséñame qué toca este diff: archivos, qué cambió en cada uno y en una frase por qué. Marca lo que no debería estar ahí (archivos de prueba, restos de intentos anteriores, secretos o valores de configuración pegados a mano).

2. QUE CORRA. Construye el proyecto y arráncalo como se arranca de verdad. No te conformes con que pasen los tests o el type check: comprueba en la superficie donde vive el código que el cambio hace lo que debe. Si truena, para aquí y dime qué truena.

3. BUGS. Con eso corriendo, busca bugs, casos borde y decisiones que van a doler después. Respeta las convenciones de mi CLAUDE.md. No apliques ningún arreglo todavía.

4. SEGURIDAD. Pasada específica sobre estos cambios: inyección, XSS, autenticación y autorización, manejo de datos sensibles y dependencias.

Entrégame un solo reporte al final, ordenado por lo que me impediría subir esto hoy. Cada hallazgo con archivo, línea, qué pasa si no se arregla y qué tan seguro estás. Si algo no se puede saber con lo que ves, dilo en vez de suponerlo.

Hay cambios donde una revisión local no alcanza: la migración de la base de datos, el refactor que toca sesenta archivos, el release que se va a producción el viernes. Para eso existe ultra, que no es «la misma revisión pero con más esfuerzo». Es otra cosa: levanta una flota de agentes en una sandbox en la nube y cada hallazgo se reproduce y se verifica de forma independiente antes de llegarte. Por eso su lista es corta y casi no trae ruido: lo que no se pudo reproducir, no se reporta.

Tarda de 5 a 10 minutos y corre en segundo plano, así que lo lanzas y sigues trabajando; el avance se sigue con /tasks. Ese tiempo es justo lo que lo saca de la rutina diaria y lo pone donde pertenece: como paso pre-merge de los cambios grandes, no como algo que corres en cada commit.

La forma sana de pensarlo: la rutina de cuatro pasos es tu default y ultra es la excepción que compras a propósito. Si terminas lanzándolo en todo, o el equipo va a sentirlo en la factura, o dejaste de confiar en una revisión que ya te estaba sirviendo.

Alrededor de /verify, /code-review y /security-review viven otros comandos que se parecen de nombre y hacen algo distinto. Confundirlos cuesta tiempo real: le pides limpieza a algo que caza bugs, o esperas hallazgos de seguridad de una pasada que solo mira estilo. Esta sección los pone en su lugar y termina con el mapa completo de dónde entra cada capa de revisión.

La regla corta para no equivocarte: /code-review busca lo que está mal, /simplify busca lo que está de más y /review mira el trabajo de otra persona. Tres verbos distintos sobre tres objetos distintos.

Todo lo de arriba es lo que sí hacen. Esta parte es la otra mitad, sin suavizar, porque son las siete cosas con las que uno se tropieza en la práctica y que ninguna publicación de lanzamiento te cuenta. Léela antes de montar un flujo de trabajo completo alrededor de estos comandos.

Ninguno de estos siete puntos es motivo para no usarlos. Son las condiciones reales de uso: tres comandos que ya tienes instalados, que atrapan bastante más de lo que se les escapa, y que rinden cuando sabes exactamente qué esperar de cada uno.

Los tres se llaman parecido y hacen trabajos distintos. Esta tabla es la que conviene tener a mano cuando dudas cuál correr: compara lo mismo en las tres columnas, incluido lo que casi nunca se compara de frente, que es cuánto tardan y cuánto cuestan.