Claude Code Prompt to Update Dependencies Safely

What this prompt does

Most "update everything" attempts fail because they treat a 200-package dependency tree as a single decision. This prompt forces the opposite: it walks each outdated package through a fixed eight-step audit — current versus latest version, changelog review, semver categorization (patch / minor / major), the exact code changes a breaking change requires, deprecated APIs you actually call, peer-dependency compatibility, and security advisories — before anything gets bumped.

It works because the structure mirrors how an upgrade actually goes wrong. Sorting by patch/minor/major separates the bumps you can batch from the ones that need eyes. Asking for deprecated APIs "we use" scopes the noise to your codebase instead of the whole changelog. And requiring tests after each major update isolates the failure to one package instead of leaving you bisecting a 40-package commit. The three variables — [update_strategy], [skip_packages], and [priority] — let you pin a risk posture, and security-first ordering is hard-coded so a CVE never waits behind a cosmetic minor bump.

When to use it

• Returning to a project that has gone months without updates and outdated prints a wall of red.
• An npm audit / composer audit / Dependabot alert flags a CVE and you need the patched version plus the code it breaks.
• Planning a framework jump (Laravel 10→11, React 18→19) where peer ranges and deprecated APIs decide the order of operations.
• Pre-release dependency hygiene when you want patches batched and majors gated behind a green test run.
• Producing a migration guide a teammate can follow, instead of an opaque lockfile diff.

Example output

## Security (do first)
- axios  0.27.2 → 1.7.9   MAJOR  (illustrative) CVE-class: SSRF via proxy handling
    Breaking: 0.x→1.x changed the proxy/adapter contract.
    Before:  axios.get(url, { proxy: { host, port } })
    After:   axios.get(url, { proxy: { protocol, host, port } })
    → patches the advisory AND crosses a major; bump in isolation, run tests

## Patch — safe to batch
- date-fns  3.6.0 → 3.6.1   bugfix only, no API change
- dotenv    16.4.5 → 16.4.7  bugfix only, no API change

## Minor — review, batch if green
- axios (post-major)  1.6.2 → 1.7.9   no breaking API; new features only

## Major — review + test each
- react-router-dom  5.3.0 → 6.28.0   BREAKING
    Before:  <Switch><Route path="/x" component={X}/></Switch>
    After:   <Routes><Route path="/x" element={<X/>}/></Routes>
    Deprecated API in use: useHistory() → useNavigate()  (4 call sites)
    Peer check: requires react >=16.8 ✓
- @testing-library/react  12.1.5 → 16.1.0   BREAKING
    Peer check: requires react >=18 ✗  (project on react@17) — hold until React bump
    → run test suite after each bump, in isolation

Pro tips

• Set [update_strategy] deliberately: "majors one PR at a time, patches batched" keeps the test-isolation step meaningful — "everything at once" quietly defeats it.
• Put framework cores in [skip_packages] on the first pass (e.g. next, laravel/framework). Clear the leaf packages, get green, then run the prompt again just for the framework with its full breaking-change attention.
• The changelog and CVE steps are only as fresh as the model's context — pair it with a tool call or paste your real npm outdated / composer outdated output so versions aren't guessed.
• Make it prove the semver call: ask it to show the version delta next to each label, so a minor masquerading as a major (or vice versa) is caught before you trust the batching.
• Tune [priority] to your reality: "dev-tooling before runtime deps" for a quiet sprint, or "runtime deps with active CVEs only" when you just need to ship a fix.
• Ask it to emit the migration guide as a checklist committed to the repo — it becomes the PR description and the rollback map if a major goes sideways.