Der Dependency Upgrade Risk Assessor: Verwandeln Sie eine Liste veralteter Pakete in einen priorisierten Upgrade-Plan
Warum dieser Prompt wichtig ist
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.
Wofür wir ihn verwenden
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
Ergebnis
| 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.
Jedes Engineering-Team sammelt einen Rückstand veralteter Abhängigkeiten an, und fast jedes Team geht auf dieselbe unbefriedigende Weise damit um: Jemand wirft einen kurzen Blick auf die Ausgabe, fühlt sich kurz schuldig und widmet sich wieder der Entwicklung von Features. Das Problem ist nicht mangelndes Bewusstsein – das Problem ist, dass es echte Zeit kostet, eine Liste von über dreißig Paketen in einen tatsächlich priorisierten Plan zu verwandeln, und diese Zeit konkurriert direkt mit der Auslieferung. Dieser Prompt wurde entwickelt, um diese Triage-Arbeit auf einen einzigen Durchlauf zu komprimieren.
Warum dieser Prompt so strukturiert ist, wie er ist
Die Einschränkung, dass das Modell jede bekannte CVE unabhängig von der angegebenen Teamkapazität automatisch als höchste Priorität behandeln muss, existiert, weil Sicherheitsfixes die einzige Kategorie von Abhängigkeitsarbeiten sind, die eigentlich nicht optional ist. Ein Prompt, bei dem „begrenzte Kapazität“ einen Sicherheitspatch stillschweigend herabstufen könnte, wäre aktiv gefährlich, wenn man sich darauf verlassen würde – der ganze Sinn der Automatisierung dieser Triage besteht darin, sicherzustellen, dass nichts Wichtiges durchrutscht, und nicht etwa eine bequeme Ausrede zu legitimieren, sie zu überspringen.
Die Unterscheidung zwischen „Das WIRD etwas beschädigen“ und „Das KÖNNTE etwas beschädigen“ ist die wichtigste Einschränkung im gesamten Prompt. Sie ist vorhanden, weil der mit Abstand häufigste Fehler von KI-gestützter Planung falsches Selbstvertrauen ist. Einem Modell, dem ein Changelog-Auszug vorgelegt wird, der eine Breaking-API-Änderung bestätigt, steht auf solidem Boden. Ein Modell, das gebeten wird zu raten, ob ein Versionssprung ohne Dokumentation sicher ist, tut etwas, das grundsätzlich weniger zuverlässig ist – und wenn beides im selben zuversichtlichen Ton präsentiert wird, wird der Plan aktiv irreführend. Das Modell dazu zu zwingen, zu kennzeichnen, in welche Kategorie jede Einschätzung fällt, bedeutet, dass Sie genau wissen, welchen Empfehlungen Sie bedenkenlos vertrauen können und welche vor dem Commit eine fünfminütige Changelog-Prüfung rechtfertigen.
Die Kapazitätsbeschränkung macht dies von einem generischen Abhängigkeitsbericht zu einem echten Sprint-Planning-Tool. Eine Risikobewertung, die ignoriert, wie viel Arbeit Ihr Team diese Woche realistischerweise bewältigen kann, ist ein Ratschlag für ein hypothetisches Team, nicht für Ihres. Die erzwungene Verkürzung auf die engere Auswahlliste „Diesen Sprint tun“ unter Berücksichtigung einer angegebenen Kapazitätszahl bedeutet, dass die Ausgabe etwas ist, das Sie direkt an das Sprint-Planning übergeben können, anstatt sie selbst umzuwandeln.
Warum das Tabellenformat wichtig ist
Eine rangierte Tabelle anstelle eines Fließtextes ist Absicht. Die Abhängigkeits-Triage ist im Grunde eine Vergleichsaufgabe – Sie wägen mehrere Pakete gegeneinander ab, um zu entscheiden, was in die begrenzte Kapazität passt –, und eine Tabelle ermöglicht es Ihnen, mental zu scannen und neu zu sortieren, wie es ein Format mit einem Absatz pro Paket nicht tut. Die abschließende Klärungsfrage zur Testabdeckung existiert, weil das größte versteckte Risiko bei jedem Upgrade mit Breaking Changes nicht die Änderung selbst ist, sondern ob Sie überhaupt bemerken, wenn sie etwas beschädigt – und das ist eine Frage, zu deren Beantwortung das Modell Sie auffordern kann, die es aber auf Ihrer eigenen Codebase nicht selbst beantworten kann.
Wie man es anpasst
Für eine Codebase mit wirklich schlechtem Changelog-Zugriff (private Pakete, aufgegebene Open-Source-Projekte mit spärlichen Release Notes) ist standardmäßig mit mehr Elementen zu rechnen, die in der Kategorie „KÖNNTE etwas beschädigen“ landen – das ist der Prompt, der korrekt funktioniert, und kein Fehler. In dieser Situation lohnt es sich, die Ausgabe vor der Finalisierung des Sprint-Plans mit einer kurzen Überprüfung der GitHub-Issues jedes Pakets auf aktuelle Bug-Reports zu kombinieren.
Für Teams, die dies vierteljährlich statt pro Sprint durchführen, tauschen Sie das Kapazitäts-Framing von „dieser Sprint“ gegen „dieses Quartal“ aus und ziehen Sie in Betracht, nach einem zweiten Durchlauf zu fragen, der Pakete nach gemeinsam genutztem zugrundeliegendem Framework gruppiert (z. B. „alle Pakete aus dem React-Ökosystem“), da Major-Version-Sprünge in einem Core-Framework oft erzwingen, dass verwandte Pakete ohnehin im Gleichschritt aktualisiert werden.