Assess the Risk of a Dependency Upgrade
Get a structured risk assessment before bumping a library across versions — what breaks, what to check, how to roll it out.
0 likes
0 dislikes
Sign in to rate this prompt
Prompt
Help me assess the risk of upgrading a dependency.
Dependency and versions (from → to): {{dependency}}
How I use it (paste the relevant code or config, or describe which features I rely on):
{{usage}}
Please assess:
1. **Breaking changes** — the changes between these versions most likely to affect my usage (removed or renamed APIs, changed defaults, dropped runtime/platform support). Note where you're inferring versus certain.
2. **What to check** — a concrete checklist of things to verify in my code before and after upgrading.
3. **Rollout** — a safe way to do the upgrade (update, run tests, check these call sites, staged deploy) and how to roll back.
Be honest about uncertainty: version-specific changelog details are easy to get wrong, so tell me where I should confirm against the official changelog or migration guide rather than trusting a guess. If you need to know my usage more precisely, ask.
Why this prompt works
-
How to Deploy an AI Agent
Every deployment problem follows from one property: you don't know how long a run takes, because you didn't write the path. Why the run m...
Read the guide → -
MCP Authorization and OAuth
Optional until you opt in, then very specific. Why the resource parameter is mandatory even when the server ignores it, why PKCE doesn't ...
Read the guide → -
MCP Transports: stdio vs Streamable HTTP
There are two transports now, not three, and the one that vanished is the one most tutorials still document. What each is exposed to, why...
Read the guide →