Código · 28 de septiembre de 2026
Encuentra por qué tu app se queda sin memoria y arréglalo paso a paso
Pega el log o el crash de out-of-memory y el código del proceso sospechoso, y recibe el diagnóstico de qué está acumulando memoria junto con el fix paso a paso.
Una fuga de memoria es de los bugs más frustrantes: no rompe nada de inmediato, solo va acumulando hasta que la app crashea sin previo aviso. Este prompt convierte el log del crash y el código sospechoso en un diagnóstico real de la causa, en vez de otro "intenta reiniciar el servidor".
Para: ClaudeChatGPTClaude Code
Prompt completo
Actúa como un ingeniero de software senior especializado en rendimiento y gestión de memoria, que diagnostica la CAUSA REAL de una fuga de memoria antes de proponer un fix, y explica todo en términos claros para alguien que no vive depurando memoria todos los días. Te voy a dar el contexto de un proceso que se está quedando sin memoria o que termina en un crash de tipo out-of-memory (OOM). Tu trabajo es encontrar qué está acumulando memoria y darme el fix exacto. Lenguaje y entorno: [EJ. Node.js 20 en un contenedor Docker, Python con Flask, Java con Spring Boot] El log o mensaje de error exacto (pega el texto tal cual, incluyendo el stack trace si hay uno): [PEGA AQUÍ EL LOG O CRASH] Cuánto tarda en quedarse sin memoria: [EJ. crashea a los 10 minutos bajo carga, o después de varios días corriendo] El código del proceso o función que sospechas (pega lo más relevante, no hace falta todo el proyecto): [PEGA AQUÍ EL CÓDIGO] Qué has intentado ya, si algo: [EJ. reinicié el servicio, subí el límite de memoria del contenedor] Entrégame: 1. Un diagnóstico corto de qué está pasando de verdad (qué se está acumulando y por qué no se libera), no solo una repetición del mensaje de error. 2. Los 2-3 sospechosos más probables en el código que pegué, señalados con el número de línea o el nombre de la función, y por qué cada uno podría causar esto. 3. El fix explicado paso a paso: qué cambiar exactamente y por qué eso resuelve la fuga (no solo "agrega esto", sino el razonamiento). 4. Una forma de confirmar que el fix funcionó (qué métrica o comando de monitoreo de memoria revisar, y qué comportamiento esperar después del cambio). 5. Si el problema puede ser una causa externa (una librería con un bug conocido, una configuración del entorno), dímelo y márcalo como [dato a verificar] si no estás seguro. Reglas anti-alucinación: no inventes nombres de funciones, variables o líneas que no te di. Si el código o el log que pegué no es suficiente para diagnosticar con certeza, dime exactamente qué información adicional necesitas antes de dar un fix definitivo.
Enlace corto: wandabuilds.ai/p/Uw7Q
Vuelve mañana por otro, o mira todos los prompts.