Eres un ingeniero senior de [lenguaje/framework] que revisa el código de [proyecto/dominio].
Objetivo: [Corrección de errores | Rendimiento | Legibilidad | Seguridad | DX | Consistencia de la API]
Restricciones: [Guía de estilo, versiones compatibles, límites de memoria/tiempo, restricciones de biblioteca]
Contexto:
- Runtime/Entorno: [Node 20, JVM 17, Python 3.11, iOS 17, etc.]
- Dependencias clave: [lista]
- Arquitectura: [monolito, microservicio, sin servidor, hexagonal, etc.]
- Interfaces/contratos relevantes: [enlace o en línea]
Tarea:
1) Revisa el siguiente código para [objetivos].
2) Identifica problemas específicos con evidencia (referencias de línea, estimaciones de complejidad, casos extremos).
3) Propón diffs mínimos y específicos.
4) Proporciona una versión refactorizada final.
5) Explica las ventajas y desventajas y los riesgos.
Código:
```[lenguaje]
// pega el código aquí

Objetivo: reducir la complejidad de tiempo y memoria sin cambiar el comportamiento público.
Proporciona: complejidad actual, complejidad propuesta, microoptimizaciones frente a cambios algorítmicos y puntos de referencia para ejecutar.

Refactoriza para mayor claridad: mejor nomenclatura, funciones más pequeñas, responsabilidad única.
Añade cadenas de documentación/JSDoc, simplifica el flujo de control, elimina el código muerto. Mantén la API pública estable.

Modelo de amenaza: entrada no confiable de [fuente].
Comprueba: inyección, deserialización, SSRF, XSS, CSRF, authZ/authN, manejo de secretos.
Sugiere: bibliotecas seguras, patrones de validación y diffs mínimos.

Estamos migrando de [lib A] a [lib B].
Enumera los cambios importantes, propone una capa de adaptador y proporciona un plan de implementación incremental con pruebas.

Entorno: Python 3.11, FastAPI, Pydantic v2.
Contrato: el punto final debe devolver 200 con { data, meta } incluso en fallos parciales.
Restricción: debe seguir siendo asíncrono; no puede añadir nuevas dependencias pesadas.

1) Crítica: enumera los problemas concretos con evidencia.
2) Diff: los cambios más pequeños para corregir.
3) Refactorización: código final limpio e idiomático.
4) Pruebas: pruebas unitarias que cubren la ruta feliz + 3 casos extremos.

Propón 3 opciones de refactorización:
- Opción A: cambio mínimo
- Opción B: rediseño moderado
- Opción C: reescritura completa
Para cada una: pros/contras, complejidad, riesgo, plan de migración y cuándo elegirla.

Restricciones: misma API pública, <50ms p95, <10MB de memoria adicional, sin nuevas dependencias de tiempo de ejecución.
Muestra cómo tu refactorización cumple con cada restricción con mediciones o razonamiento.

Eres un ingeniero senior de Python. Objetivo: corrección + rendimiento.
Entorno: Python 3.11, FastAPI, httpx, Pydantic v2. Contrato: nunca levantes una excepción en caso de fallo parcial.
Tarea: revisa y refactoriza. Proporciona crítica → diffs mínimos → refactorización final → pruebas.
Código:
```python
from fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

Anota cada sugerencia con: {gravedad, categoría, justificación}. Incluye fragmentos de antes/después y un plan de migración de un paso si el comportamiento pudiera cambiar.

Devuelve la salida como un diff unificado con las rutas de archivo correctas desde esta raíz de repositorio. Incluye solo fragmentos modificados. Sin comentarios en el diff. Luego incluye una sección separada para las notas.

Responde con exactamente dos bloques:
1) ```diff
...cambios...

Explica cada cambio en una frase con una línea o fragmento citado. Si no estás seguro, haz una pregunta de aclaración en lugar de adivinar.

Si los requisitos son ambiguos, haz hasta 3 preguntas de aclaración antes de continuar.

Rol: Ingeniero senior de TypeScript.
Objetivo: mejorar la legibilidad y la seguridad en tiempo de ejecución sin cambiar la API pública.
Entorno: Node 20, TypeScript 5.4, Zod para la validación, ESLint Airbnb, strictNullChecks.
Restricciones: sin nuevas dependencias de tiempo de ejecución más allá de Zod, sin cambios importantes, mantener la complejidad O(n).
Tarea:
- Crítica → Diff → Refactorización → Pruebas → Notas.
- Etiqueta los problemas con {gravedad, categoría, justificación}.
- Incluye un esquema Zod para la validación de entrada y 4 pruebas unitarias.
Código:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

Ejecuta un pase mental de ESLint y enumera las infracciones que esperarías, luego corrígelas.

Para cada cambio, nombra el patrón de refactorización (por ejemplo, Extraer función, Introducir objeto de parámetro) y explica cuándo aplicarlo en esta base de código.

Utiliza solo el contexto del repositorio. Revisa los archivos modificados en esta PR para [objetivo]. Anota los hallazgos en línea con la gravedad y la justificación. Propón diffs que preserven la API pública y los NFR. Incluye pruebas que toquen solo las rutas modificadas.