O Avaliador de Risco de Atualização de Dependências: Transforme uma Lista de Pacotes Desatualizados em um Plano de Atualização Classificado
Porque é que este prompt importa
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 que o 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.
Toda equipa de engenharia acumula uma lista de dependências desatualizadas, e quase todas as equipas lidam com isso da mesma forma insatisfatória: alguém olha para o resultado, sente uma breve culpa e passa para o trabalho de novas funcionalidades. O problema não é a falta de consciencialização — é que transformar uma lista de mais de trinta pacotes num plano priorizado real exige tempo real, e esse tempo concorre diretamente com a entrega. Este prompt foi criado para comprimir esse trabalho de triagem numa única passagem.
Porque é que este prompt está estruturado desta forma
A restrição que exige que o modelo trate qualquer CVE conhecido como prioridade máxima automática, independentemente da capacidade declarada da equipa, existe porque as correções de segurança são a única categoria de trabalho de dependência que não é realmente opcional. Um prompt que permitisse que a "capacidade limitada" despriorizasse silenciosamente um patch de segurança seria perigoso para confiar — o objetivo principal de automatizar esta triagem é garantir que nada de importante escape, e não servir de desculpa conveniente para o saltar.
A distinção entre "isto VAI quebrar alguma coisa" e "isto PODE quebrar alguma coisa" é a restrição mais importante em todo o prompt, e está lá porque o modo de falha mais comum do planejamento assistido por IA é a falsa confiança. Um modelo que recebe um excerto de changelog a confirmar uma alteração que quebra a compatibilidade de uma API está em terreno sólido. Um modelo a quem se pede para adivinhar se um salto de versão sem documentação é seguro está a fazer algo fundamentalmente menos fiável — e se ambos forem apresentados com o mesmo tom confiante, o plano torna-se ativamente enganador. Forçar o modelo a sinalizar em que categoria cada avaliação se enquadra significa que sabes exatamente em que recomendações podes confiar pelo valor nominal e quais justificam uma verificação de cinco minutos no changelog antes de te comprometeres com elas.
A restrição de capacidade é o que transforma isto de um relatório de dependências genérico numa ferramenta de planeamento de sprint real. Uma avaliação de risco que ignora quanto trabalho a tua equipa consegue realisticamente absorver esta semana é conselho para uma equipa hipotética, não para a tua. Forçar a lista curta de "Fazer Este Sprint" a respeitar um número de capacidade indicado significa que o resultado é algo que podes entregar diretamente ao planeamento de sprint em vez de o traduzires tu mesmo.
Porque é que o formato de tabela importa
Uma tabela classificada, em vez de um texto narrativo, é deliberada. A triagem de dependências é fundamentalmente uma tarefa de comparação — estás a ponderar vários pacotes uns contra os outros para decidir o que cabe numa capacidade limitada — e uma tabela permite-te analisar e reordenar mentalmente de uma forma que um formato de parágrafo por pacote não permite. A pergunta de esclarecimento final sobre a cobertura de testes existe porque o maior risco oculto em qualquer atualização que quebra a compatibilidade não é a alteração em si, mas sim se vais realmente dar por ela se algo quebrar — e essa é uma pergunta que o modelo te pode pedir para responder, mas que não consegue responder na tua própria base de código.
Como adaptá-lo
Para uma base de código com acesso genuinamente pobre a changelogs (pacotes privados, projetos de código aberto abandonados com notas de lançamento escassas), espera que mais itens fiquem na categoria "PODE quebrar alguma coisa" por predefinição — isso é o prompt a funcionar corretamente, e não a falhar. Nessa situação, vale a pena emparelhar o resultado com uma verificação rápida dos problemas do GitHub de cada pacote para relatórios de bugs recentes antes de finalizar o plano de sprint.
Para equipas que executam isto trimestralmente em vez de por sprint, troca o enquadramento de capacidade de "este sprint" para "este trimestre", e considera pedir uma segunda passagem que agrupe pacotes por um Framework subjacente partilhado (por exemplo, "todos os pacotes do ecossistema React"), uma vez que saltos de versão principal num Framework central muitas vezes obrigam os pacotes relacionados a atualizar em conjunto.