El Evaluador de Riesgos de Actualización de Dependencias: Convierte una lista de paquetes desactualizados en un plan de actualización jerarquizado
Por qué importa este prompt
Dependency debt compounds silently. Each deferred upgrade doesn't just add one more overdue package — it makes the eventual upgrade riskier, because more changes stack up between your current version and the one you'll be forced onto during a security incident or an end-of-life deadline. Teams that never explicitly prioritize upgrades don't avoid the work; they just do it later, under worse conditions, usually as an unplanned emergency instead of a scheduled sprint task.
Para qué lo usamos
Your `npm outdated` output lists 34 packages behind, most flagged for major-version gaps. Your tech lead wants a prioritized upgrade plan before tomorrow's sprint planning, and you don't have time to read every changelog yourself.
Prompt
Act as a senior engineer responsible for dependency management who has run upgrade cycles across dozens of production codebases and knows how deferred upgrades turn into emergency migrations. Context: Project type and stack: [e.g., "Node.js/TypeScript monorepo, ~200k LOC, deployed to production weekly"] Outdated dependencies: [PASTE THE LIST — package name, current version, latest version, e.g. from `npm outdated`, `pip list --outdated`, or `bundle outdated`] Changelog or release-notes excerpts, if you have them: [PASTE RELEVANT EXCERPTS, OR WRITE "NONE PROVIDED" FOR ANY PACKAGE] Team capacity this sprint: [e.g., "limited — can only take on 2-3 low-risk upgrades" or "dedicated tech-debt sprint, can absorb larger changes"] Task: For each dependency listed, assess: 1. How many major and minor versions behind it currently is 2. Its risk category — security-critical, breaking-change-heavy, or routine 3. A specific recommendation: upgrade now, schedule for next sprint, or defer (with a reason) Constraints: - Flag any dependency with a known CVE or security advisory as highest priority regardless of stated team capacity. - Clearly distinguish between "this WILL break something" (based on documented breaking changes you were given) and "this MIGHT break something" (no changelog provided, so assume moderate risk) — never present a guess with the same confidence as a documented fact. - The "upgrade now" shortlist must respect the stated team capacity — do not recommend more work than the team can realistically absorb this sprint. - If changelog excerpts weren't provided for a package, say so explicitly in your reasoning rather than inventing specific breaking changes. Output Format: 1. A ranked table: Package | Current → Latest | Risk Level | Recommendation | Reasoning 2. A "Do This Sprint" shortlist that respects the stated capacity 3. One clarifying question to ask before greenlighting the single riskiest upgrade on the list
Resultado
| Package | Current → Latest | Risk Level | Recommendation | Reasoning |
|---|---|---|---|---|
| auth-token-lib | 2.3.1 → 2.3.9 | Security-Critical | Upgrade now | Changelog for 2.3.7 lists a fix for CVE-2026-31442, a token-validation bypass. This overrides capacity limits — security fixes are non-negotiable regardless of sprint load. |
| axios | 0.21.4 → 1.7.2 | Breaking-Change-Heavy | Schedule for next sprint | Major version jump (0.x → 1.x). Changelog confirms the default export pattern changed and several config options were renamed. This WILL require code changes across every file that imports axios directly — not a drop-in bump. |
| lodash | 4.17.15 → 4.17.21 | Routine | Upgrade now | Patch-only jump within the same minor version. No changelog excerpt was provided, but the version delta itself (patch-level only) makes breaking changes very unlikely. Low effort, safe to batch with the security fix above. |
| express | 4.17.1 → 4.19.2 | Routine | Upgrade now | Minor version bumps within Express 4.x have historically been backward-compatible. No changelog was provided for this specific range, so this is a moderate-confidence assessment, not a documented guarantee. |
| react | 17.0.2 → 18.3.1 | Breaking-Change-Heavy | Defer | Major version jump requiring the new root API (createRoot) and auditing all components for concurrent-rendering side effects. Given your stated capacity of 2-3 upgrades this sprint, this is too large to absorb alongside the security fix — defer to the dedicated tech-debt sprint. |
Do This Sprint (respecting stated capacity of 2-3 upgrades):
- auth-token-lib (security-critical, mandatory)
- lodash (near-zero risk, low effort)
- express (routine, moderate confidence)
Clarifying question before greenlighting axios 1.x: Do you have integration test coverage on every code path that calls axios directly, or only on the handful of endpoints your team remembers using it? A breaking-change-heavy upgrade is far riskier in code paths without test coverage, since you won't catch a broken call signature until it fails in production.
Cada equipo de ingeniería acumula una acumulación de dependencias obsoletas, y casi todos los equipos lo manejan de la misma manera insatisfactoria: alguien echa un vistazo al resultado, siente una breve culpa y pasa al trabajo de nuevas características. El problema no es la falta de conciencia; es que convertir una lista de más de treinta paquetes en un plan priorizado real toma tiempo real, y ese tiempo compite directamente con el lanzamiento. Este prompt está diseñado para comprimir ese trabajo de triaje en una sola pasada.
Por qué este prompt está estructurado de esta manera
La restricción que requiere que el modelo trate cualquier CVE conocido como de máxima prioridad automática, independientemente de la capacidad declarada del equipo, existe porque las correcciones de seguridad son la única categoría de trabajo de dependencias que en realidad no es opcional. Un prompt que permitiera que la "capacidad limitada" despriorizara silenciosamente un parche de seguridad sería activamente peligroso para confiar en él; el objetivo principal de automatizar este triaje es asegurarse de que nada importante se pase por alto, no blanquear una excusa conveniente para omitirlo.
La distinción entre "esto ROMPERÁ algo" y "esto PODRÍA romper algo" es la restricción más importante en todo el prompt, y está ahí porque el modo de fallo más común de la planificación asistida por IA es la falsa confianza. A un modelo al que se le da un extracto de registro de cambios que confirma un cambio disruptivo en la API se le sitúa sobre terreno firme. A un modelo al que se le pide que adivine si un salto de versión sin documentación es seguro se le pide algo fundamentalmente menos confiable, y si ambos se presentan con el mismo tono seguro, el plan se vuelve activamente engañoso. Forzar al modelo a señalar en qué categoría cae cada evaluación significa que sabes exactamente qué recomendaciones se pueden tomar al pie de la letra y cuáles ameritan una revisión de cinco minutos del registro de cambios antes de comprometerte con ellas.
La restricción de capacidad es lo que convierte esto de un informe de dependencia genérico en una verdadera herramienta de planificación de sprint. Una evaluación de riesgos que ignora cuánto trabajo puede absorber de manera realista tu equipo esta semana es un consejo para un equipo hipotético, no para el tuyo. Forzar a que la lista corta de "Hacer este Sprint" respete un número de capacidad declarado significa que el resultado es algo que puedes entregar directamente a la planificación de sprint en lugar de tener que traducirlo tú mismo.
Por qué importa el formato de tabla
Una tabla clasificada, en lugar de un escrito narrativo, es deliberada. El triaje de dependencias es fundamentalmente una tarea de comparación: estás sopesando varios paquetes entre sí para decidir qué cabe en una capacidad limitada, y una tabla te permite escanear y reordenar mentalmente de una manera que un formato de un párrafo por paquete no permite. La pregunta aclaratoria final sobre la cobertura de pruebas existe porque el mayor riesgo oculto en cualquier actualización con cambios disruptivos no es el cambio en sí, sino si realmente notarás si algo se rompe, y esa es una pregunta que el modelo puede pedirte que respondas, pero que no puede responder sobre tu propia base de código.
Cómo adaptarlo
Para una base de código con acceso genuinamente deficiente a los registros de cambios (paquetes privados, proyectos de código abierto abandonados con notas de lanzamiento escasas), espera que más elementos caigan en la categoría "PODRÍA romper algo" de manera predeterminada; eso es el prompt funcionando correctamente, no fallando. En esa situación, vale la pena combinar el resultado con una rápida verificación de los problemas de GitHub de cada paquete en busca de informes de errores recientes antes de finalizar el plan de sprint.
Para los equipos que ejecutan esto trimestralmente en lugar de por sprint, cambie el enfoque de capacidad de "este sprint" a "este trimestre", y considere pedir una segunda pasada que agrupe los paquetes por un Framework subyacente compartido (por ejemplo, "todos los paquetes del ecosistema React"), ya que los saltos de versión principal en un Framework central a menudo obligan a actualizar los paquetes relacionados al mismo paso de todos modos.