Nota del autor: He recopilado 25 indicaciones (prompts) para revisiones de código con Claude Code, validadas en entornos reales y que cubren 7 escenarios clave: revisión de seguridad, análisis de rendimiento, revisión de arquitectura, detección de errores, revisión de PR, entre otros. Además, incluyo una fórmula para redactar tus propias indicaciones.
Claude Code incluye el comando /security-review y un sistema multi-agente para revisiones de código, pero a menudo, la salida predeterminada es demasiado verbosa y se pierde en detalles irrelevantes. Una buena indicación para una revisión debe ser tan precisa como un caso de prueba: definir el alcance, establecer prioridades y exigir números de línea específicos junto con sugerencias de corrección. En este artículo, presento 25 indicaciones para 7 escenarios de revisión de código, desde seguridad hasta arquitectura, listas para copiar y usar.
Valor principal: 25 indicaciones que cubren los escenarios más frecuentes de revisión de código, acompañadas de una fórmula de redacción y ejemplos de buenas y malas prácticas.
Fórmula para redactar indicaciones de revisión
Una buena indicación de revisión es tan precisa como un caso de prueba. Una mala indicación de revisión es como un mensaje vago de Slack.
Fórmula de cinco elementos
[Rol] Desde la perspectiva de un ingeniero senior en {lenguaje/área}
[Alcance] Revisa el {archivo/directorio/PR} con los {cambios realizados}
[Enfoque] Prioriza {seguridad/rendimiento/lógica/arquitectura}
[Formato] Formato de salida: {lista numerada/tabla/comentarios en línea}
[Nivel] Clasifica la gravedad: {Crítica/Alta/Media/Baja}
| Elemento | Ejemplo deficiente | Buen ejemplo |
|---|---|---|
| Rol | (No definido) | "Desde la perspectiva de un ingeniero backend senior" |
| Alcance | "Revisa este código" | "Revisa el git diff reciente de src/auth/" |
| Enfoque | "Dame feedback" | "Prioriza inyecciones SQL y omisiones de autenticación" |
| Formato | (Salida libre) | "Lista numerada, cada ítem debe incluir: archivo:línea, descripción del problema, sugerencia de corrección" |
| Nivel | (No solicitado) | "Clasifica en Crítica/Alta/Media/Baja" |
Escenario 1: Revisión de seguridad (4 indicaciones)
La revisión de seguridad es el escenario de mayor prioridad en una Code Review. Claude Code incluye el comando /security-review, pero las indicaciones personalizadas pueden profundizar mucho más.
Indicación #1: Escaneo integral OWASP Top 10
Desde la perspectiva de un ingeniero de auditoría de seguridad, revisa todos los archivos modificados recientemente en el directorio src/.
Verifica punto por punto según OWASP Top 10:
1. Inyección (SQL/NoSQL/Inyección de comandos)
2. Fallos de autenticación
3. Exposición de datos sensibles
4. XXE
5. Fallos de control de acceso
6. Configuración de seguridad incorrecta
7. XSS
8. Deserialización insegura
9. Uso de componentes con vulnerabilidades conocidas
10. Registro y monitoreo insuficientes
Formato de salida: lista numerada, cada ítem debe incluir [archivo:línea] [nivel de gravedad] [descripción del problema] [sugerencia de corrección].
Reporta solo problemas reales, no riesgos teóricos.
Indicación #2: Revisión de seguridad de endpoints de API
Revisa todos los archivos de rutas de API (routes/, controllers/), enfocándote en:
- Endpoints que carezcan de middleware de autenticación
- Si los parámetros cuentan con validación y saneamiento de entrada
- Riesgos de asignación masiva (mass assignment)
- Configuración de limitación de tasa (rate limiting)
- Si las respuestas de error filtran información interna
Formato de salida (tabla): Ruta del endpoint | Problema | Nivel de gravedad | Solución propuesta
Indicación #3: Detección de fugas de información sensible
Escanea todo el proyecto para verificar si la siguiente información sensible está hardcodeada o expuesta accidentalmente:
- Claves API, secretos, tokens
- Cadenas de conexión a bases de datos
- Claves privadas y certificados
- IPs internas y nombres de dominio
- Contraseñas o credenciales en comentarios
El alcance de la revisión incluye: código fuente, archivos de configuración, .env.example, docker-compose.yml, README
Indica la ruta del archivo y el número de línea de cada hallazgo.
Indicación #4: Revisión de lógica de autenticación y autorización
Desde la perspectiva de un experto en seguridad, revisa el código relacionado con la autenticación y autorización:
1. ¿Es completa la lógica de validación de tokens JWT (expiración, firma, manipulación)?
2. ¿Se utiliza hashing seguro para el almacenamiento de contraseñas (bcrypt/argon2)?
3. ¿La gestión de sesiones es vulnerable a ataques de fijación de sesión?
4. ¿La configuración de CORS es demasiado permisiva?
5. ¿El callback de OAuth verifica el parámetro state?
Reporta solo problemas de nivel Crítico y Alto, incluyendo ejemplos de código para la corrección.
Escenario 2: Detección de errores (4 indicaciones)
Indicación #5: Punteros nulos y condiciones de contorno
Revisa los archivos modificados recientemente en busca de posibles errores:
- Acceso a propiedades sin verificar si son null/undefined
- Acceso a índices fuera de los límites de un array
- Errores de división por cero
- Cadenas vacías no gestionadas
- parseInt/parseFloat sin manejar NaN
Para cada hallazgo, indica las condiciones de activación (qué entrada provocaría el fallo) y el código de corrección.
Indicación #6: Problemas de asincronía y concurrencia
Revisa todo el código asíncrono del proyecto (async/await, Promise, callbacks), verificando:
- Promesas sin un .catch para el manejo de errores
- Condiciones de carrera (race conditions)
- Uso de await dentro de bucles que provoca ejecución secuencial (debería usarse Promise.all)
- Callback hell que pueda ser refactorizado
- Si las transacciones gestionan correctamente el rollback
Marca el resultado como [Archivo:Número de línea] [Problema] [Impacto] [Solución]
Indicación #7: Cazador de errores lógicos
Lee atentamente la lógica de negocio de las siguientes funciones buscando:
- Si las ramas if/else cubren todos los casos
- Si las condiciones de terminación de los bucles son correctas
- Si los operadores de comparación son adecuados (== vs ===, > vs >=)
- Si el alcance de las variables es correcto
- Si los valores de retorno están definidos en todas las rutas
No te centres en el estilo del código, solo en la corrección lógica.
Indicación #8: Revisión del manejo de errores
Revisa el mecanismo de manejo de errores del proyecto:
1. ¿Los bloques try/catch capturan excepciones específicas en lugar de un Error genérico?
2. ¿Los bloques catch simplemente ignoran el error (catch vacío)?
3. ¿Se propagan correctamente los errores a las capas superiores?
4. ¿Los mensajes de error visibles para el usuario son amigables (sin exponer información interna)?
5. ¿Las operaciones críticas (pagos, cambios de datos) tienen mecanismos de rollback ante fallos?
Ordena los resultados por nivel de gravedad.
Escenario 3: Análisis de rendimiento (3 indicaciones)
Indicación #9: Rendimiento de consultas a bases de datos
Revisa todo el código de consultas a base de datos (models/, repositories/, llamadas a ORM), verificando:
- Problemas de consultas N+1 (consultas ejecutadas dentro de bucles)
- Campos de consulta que carecen de índices
- Si SELECT * debería reemplazarse por campos específicos
- Si las consultas de grandes volúmenes de datos tienen paginación
- Si hay consultas repetidas que podrían optimizarse con caché
Para cada problema, estima el impacto en el rendimiento (bajo/medio/alto) y proporciona el código optimizado.
Indicación #10: Fugas de memoria y recursos
Revisa posibles fugas de memoria y recursos en el proyecto:
- ¿Se eliminan los escuchadores de eventos al desmontar componentes?
- ¿Se limpian los temporizadores (setInterval/setTimeout)?
- ¿Se cierran correctamente las conexiones a la base de datos?
- ¿Se liberan los manejadores de archivos en bloques finally?
- ¿Se eliminan las referencias a arrays/objetos grandes después de su uso?
Concéntrate en la limpieza de useEffect en componentes React y en el procesamiento de streams en Node.js.
Indicación #11: Revisión de complejidad algorítmica
Revisa las funciones modificadas recientemente y analiza su complejidad temporal y espacial:
- ¿Hay implementaciones con complejidad O(n²) o superior que puedan optimizarse?
- ¿Hay lugares donde se pueda sustituir una búsqueda lineal por una tabla hash?
- ¿Hay copias profundas (deep copies) innecesarias?
- ¿Debería usarse StringBuilder/join para la concatenación de cadenas?
- ¿Se está utilizando el algoritmo de ordenación adecuado?
Marca el resultado como: Complejidad actual → Complejidad optimizable → Solución de optimización específica.
Escenario 4: Revisión de arquitectura (4 indicaciones)
Indicación #12: Análisis de dependencias y acoplamiento
Analiza las dependencias de los módulos en src/:
1. Dibuja un diagrama de dependencias entre módulos (qué módulo importa a cuáles).
2. Identifica dependencias circulares.
3. Identifica los módulos con mayor acoplamiento (aquellos de los que dependen más otros módulos).
4. Sugiere qué dependencias deberían desacoplarse mediante interfaces o abstracciones.
Salida: Tabla de relaciones de dependencia + lista de dependencias circulares + sugerencias de desacoplamiento.
Indicación #13: Verificación de cumplimiento de arquitectura en capas
Comprueba si el código sigue los principios de arquitectura en capas:
- ¿La capa Controller contiene lógica de negocio? (Debería limitarse al enrutamiento y validación de parámetros).
- ¿La capa Service opera directamente sobre la base de datos? (Debería hacerlo a través del Repository).
- ¿La capa Model/Entity contiene lógica relacionada con HTTP?
- ¿Existen llamadas entre capas no permitidas? (Por ejemplo, un Controller llamando directamente a un Repository).
Enumera cada archivo que viole los principios de capas y la ubicación exacta del código.
Indicación #14: Revisión de diseño de API
Revisa todos los endpoints de la API desde la perspectiva de las mejores prácticas de diseño RESTful:
- ¿La nomenclatura de las URL sigue las convenciones REST? (sustantivos en plural, relaciones jerárquicas).
- ¿El uso de los métodos HTTP es correcto? (GET para solo lectura, POST para creación, PUT para actualización, DELETE para eliminación).
- ¿El formato de respuesta es consistente? (códigos de error, formato de paginación, formato de fecha).
- ¿El control de versiones de la API es adecuado?
- ¿Existen endpoints redundantes que puedan fusionarse?
Salida: Tabla de sugerencias de mejora (Actual → Sugerencia → Razón).
Indicación #15: Evaluación de deuda técnica
Realiza una evaluación integral de la deuda técnica del proyecto:
1. Paquetes de dependencias y versiones de frameworks obsoletos.
2. Llamadas a API obsoletas (deprecated).
3. Valores de configuración codificados (deberían usar variables de entorno).
4. Bloques de código duplicados (copiar y pegar).
5. Módulos críticos sin pruebas unitarias.
6. Funciones demasiado complejas (complejidad ciclomática > 15).
Ordena por urgencia de reparación: Bloqueante (debe repararse de inmediato) > Alta > Media > Baja.
Escenario 5: Revisión de PR (4 indicaciones)
Indicación #16: Revisión rápida de Diff en PR
Revisa el diff de la rama actual frente a main y evalúa desde la perspectiva de un ingeniero senior:
1. ¿Cuál es el propósito de este PR? (deducido a partir del diff).
2. ¿Los cambios están completos? (¿hay archivos o lógica omitidos?).
3. ¿Se han introducido nuevos errores o regresiones?
4. ¿La cobertura de pruebas es suficiente?
5. ¿Hay cambios innecesarios? (código de depuración, ruido de formato).
Reporta solo problemas de nivel Alto y Crítico. No te centres en detalles triviales de estilo de código (nit-picking).
Indicación #17: Verificación de compatibilidad hacia atrás
Revisa todos los cambios del PR actual para comprobar si hay modificaciones incompatibles hacia atrás:
- ¿Se ha cambiado la firma o el valor de retorno de alguna interfaz de API pública?
- ¿El esquema de la base de datos tiene cambios disruptivos (breaking changes)?
- ¿Ha cambiado el formato de los archivos de configuración?
- ¿Se han eliminado funciones utilizadas por otros módulos?
- ¿Se ha cambiado el nombre o formato de las variables de entorno?
Para cada elemento incompatible, evalúa el alcance del impacto y el plan de migración.
Indicación #18: Revisión de suficiencia de pruebas
Compara los cambios de código del PR actual con los cambios en las pruebas:
1. ¿Las funciones nuevas tienen sus correspondientes pruebas unitarias?
2. ¿Se ha actualizado la lógica de las pruebas existentes tras modificar el código?
3. ¿Las condiciones de contorno y las rutas de excepción tienen cobertura de pruebas?
4. ¿Las pruebas de integración cubren los nuevos endpoints de la API?
5. ¿Los datos de prueba son razonables? (evitar valores aleatorios como 123 o abc).
Enumera las sugerencias de casos de prueba faltantes: Nombre de la función | Escenario de prueba faltante | Prioridad.
Indicación #19: Revisión de calidad de los Commit
Revisa el historial de commits del PR actual:
1. ¿El mensaje del commit describe claramente el contenido del cambio?
2. ¿Cada commit es atómico? (un commit para un solo propósito).
3. ¿Hay commits triviales que deberían ser combinados (squash)?
4. ¿Hay commits temporales como "fix typo" o "wip" que deberían limpiarse?
5. ¿El orden de los commits es lógico? (primero infraestructura, luego lógica de negocio).
Sugiere los commits que necesitan reorganizarse y la estructura final de los mismos.
Escenario 6: Legibilidad (3 indicaciones)
Indicación #20: Revisión de nombres
Revisa los nombres de todas las variables, funciones y clases en los archivos modificados recientemente:
- ¿Hay nombres con significados ambiguos (data, info, temp, res, obj)?
- ¿Hay abreviaturas excesivas (usr → user, btn → button)?
- ¿Hay nombres de valores booleanos que no comienzan con is/has/should?
- ¿Los nombres de las funciones comienzan con un verbo que describa con precisión el comportamiento?
- ¿Los nombres de las clases comienzan con un sustantivo que describa con precisión su responsabilidad?
Para cada nombre inadecuado, proporciona una alternativa mejor.
Indicación #21: Revisión de la calidad de los comentarios
Revisa la calidad de los comentarios en el código:
- ¿Hay comentarios de tipo "qué" (what) que deberían cambiarse a comentarios de tipo "por qué" (why)?
- ¿Hay comentarios obsoletos (que no coinciden con el código)?
- ¿Hay comentarios que deberían extraerse como nombres de funciones?
- ¿Faltan comentarios explicativos en la lógica de negocio compleja?
- ¿Las API públicas tienen JSDoc/docstrings?
No sugieras añadir comentarios obvios (como "// incrementar contador").
Indicación #22: Sugerencias de división de funciones
Revisa todas las funciones de más de 30 líneas y evalúa si deben dividirse:
- ¿La función tiene múltiples responsabilidades (hace varias cosas no relacionadas)?
- ¿El nivel de anidamiento supera los 3 niveles?
- ¿El número de parámetros supera los 4?
- ¿Hay lógica repetida que se pueda extraer?
Proporciona un plan de división específico: función original → lista de funciones divididas → responsabilidad de cada función.
Escenario 7: Sugerencias de refactorización (3 indicaciones)
Indicación #23: Detección de violación de DRY
Escanea el proyecto en busca de código duplicado:
- Identifica bloques de código repetidos de más de 3 líneas.
- Identifica código con lógica similar pero escrita de forma diferente.
- Identifica patrones comunes que puedan extraerse como funciones de utilidad.
Para cada grupo de código duplicado, proporciona el código de implementación específico extraído como una función común.
Indicación #24: Optimización de patrones de diseño
Revisa el código desde la perspectiva de un experto en patrones de diseño:
- ¿Deberían reemplazarse grandes bloques de if/else o switch por el patrón de estrategia?
- ¿Debería usarse el patrón de fábrica/constructor para la creación de objetos complejos?
- ¿Debería usarse el patrón de método de plantilla para el código repetitivo?
- ¿Deberían reemplazarse las devoluciones de llamada (callbacks) anidadas por el patrón de cadena de responsabilidad?
- ¿Debería usarse el patrón de observador para la gestión del estado global?
Sugiere cambios solo si la mejora del patrón reduce significativamente la complejidad; evita el diseño excesivo.
Indicación #25: Modernización de código heredado
Revisa el código heredado del proyecto y encuentra partes que puedan reescribirse con sintaxis moderna:
- var → const/let
- Callbacks → async/await
- bucles for → map/filter/reduce
- concatenación de cadenas → plantillas de cadena (template strings)
- require → import
- Class → componentes de función + Hooks (React)
Proporciona una comparación del código antes y después de la refactorización y evalúa el riesgo de la misma (bajo/medio/alto).
🎯 Consejos de uso: Se recomienda guardar las indicaciones de revisión más utilizadas en
CLAUDE.mdo.claude/skills/para estandarizarlas en el equipo. A través de/loop, puedes automatizar las revisiones de seguridad y las revisiones de PR.
Si construyes un sistema de revisión automatizado a través de una API, te recomendamos conectarte a Claude Opus 4.6 a través de APIYI (apiyi.com) con un 20% de descuento.
Preguntas frecuentes
Q1: ¿Qué hago si el comando /code-review predeterminado es demasiado verboso?
Crea un archivo REVIEW.md en la raíz del proyecto o añade reglas de revisión en CLAUDE.md para indicarle claramente a Claude en qué debe enfocarse y qué debe ignorar. Por ejemplo: "Reporta solo problemas de nivel Crítico y Alto. No seas quisquilloso con el estilo de código o los nombres. No sugieras añadir comentarios". Claude Code leerá este archivo automáticamente en cada revisión.
Q2: ¿Cómo puedo guardar una indicación como una habilidad reutilizable?
Guarda tu indicación de revisión de seguridad en .claude/skills/security-review/SKILL.md y configura user-invocable: true. Esto la registrará como un comando de barra diagonal /security-review. A partir de ese momento, podrás ejecutarla directamente escribiendo /security-review sin tener que copiar y pegar cada vez. Puedes guardar múltiples indicaciones como habilidades distintas.
Q3: ¿Puede la revisión de PR publicarse automáticamente como comentarios en GitHub?
Sí. Hay dos formas: 1) Escribe @claude review en un comentario del PR; Claude analizará automáticamente el diff y publicará los hallazgos como comentarios en línea. 2) Usa el comando /code-review --comment, y Claude publicará los resultados de la revisión como un comentario en el PR. En marzo de 2026, Anthropic lanzó un sistema multi-agente especializado en revisión de código, capaz de coordinar un grupo de agentes profesionales para examinar los PR desde múltiples ángulos, como seguridad, lógica y pruebas.
Q4: ¿Cuántos tokens consume una indicación de revisión?
Depende del alcance de la revisión. Una revisión de un solo archivo consume entre 2000 y 5000 tokens, mientras que un escaneo de seguridad de todo el proyecto puede consumir entre 10 000 y 30 000 tokens. Se recomienda limitar el alcance de la revisión a archivos o directorios específicos para evitar desperdiciar tokens "escaneando todos los archivos". Puedes reducir significativamente los costos de revisión accediendo a Claude Opus 4.6 con un 20% de descuento a través de APIYI en apiyi.com.
Resumen
Puntos clave sobre las indicaciones para la revisión de código con Claude Code:
- 25 indicaciones que cubren 7 escenarios: Revisión de seguridad (4), detección de errores (4), análisis de rendimiento (3), revisión de arquitectura (4), revisión de PR (4), legibilidad (3) y sugerencias de refactorización (3); listas para copiar y usar.
- La fórmula de los cinco elementos para una buena indicación: Rol + Alcance + Enfoque + Formato + Nivel de severidad. Sé tan preciso como en un caso de prueba, no seas ambiguo como en un mensaje de Slack.
- Sistema de revisión de tres niveles: Comandos integrados (/security-review) → Indicaciones personalizadas (las 25 de este artículo) → Automatización de revisión continua con /loop.
Te recomendamos acceder a la API de Claude Opus 4.6 con un 20% de descuento a través de APIYI (apiyi.com) para construir tu sistema de revisión de código automatizado.
📚 Referencias
-
Documentación oficial de Claude Code Code Review: Explicación completa de la función de revisión integrada
- Enlace:
code.claude.com/docs/en/code-review - Descripción: Incluye revisión de PR, sistemas multi-agente y métodos de personalización
- Enlace:
-
Claude Code Security Review: Esquema oficial de revisión de seguridad de Anthropic
- Enlace:
github.com/anthropics/claude-code-security-review - Descripción: Contiene la implementación completa del comando /security-review
- Enlace:
-
7 indicaciones para Claude PR Review: Indicaciones de revisión validadas por la comunidad
- Enlace:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - Descripción: Incluye plantillas de indicación estructuradas para la revisión de PR
- Enlace:
-
Centro de documentación de APIYI: Acceso a la API de Claude Opus 4.6 con un 20% de descuento
- Enlace:
docs.apiyi.com - Descripción: La mejor solución de API para construir sistemas de revisión automatizados
- Enlace:
Autor: Equipo técnico de APIYI
Intercambio técnico: Te invitamos a participar en la sección de comentarios. Para más información, visita el centro de documentación de APIYI en docs.apiyi.com
