# Update Dependencies

> Update a project's dependencies to their latest versions and validate the upgrade - check changelogs for breaking changes, fix what's easy, hold back what the framework pins, and report what needs a decision. Use when the user asks to update, upgrade, or bump dependencies/packages, check for outdated packages, or asks what's new in their dependencies.

- Skill: `50bytesofjohn/update-dependencies` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 50bytesofjohn/update-dependencies`
- Raw SKILL.md: https://api.skillmd.com/api/skills/50bytesofjohn/update-dependencies/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: MIT
- Author: 50BytesOfJohn (https://skillmd.com/u/50bytesofjohn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/50bytesofjohn/update-dependencies

---


# Update dependencies

Update every dependency to its latest version, recursively across the workspace, then prove
the project still works.

## 1. See what's outdated

`pnpm outdated` / `npm outdated` / `yarn outdated`. Cover every workspace package, not just
the root.

## 2. Read the changelog before you bump

Validate **every major and minor** change. Never rely on training data for what a version did.

- `gh api repos/<org>/<repo>/releases` - fastest source of real release notes
- `ctx7` CLI for migration guides and current API docs
- web search as fallback

Then grep the codebase for what actually changed. A removed field nobody uses is not a
breaking change.

## 3. Hold back what the framework pins

If a framework caps a dependency through its peers or transitive deps (Next.js on ESLint,
say), skip that upgrade. Never force it with overrides or resolutions - report it instead.

## 4. Apply and verify

Run the upgrade, then run typecheck, tests, lint, and build etc. depending on project.

## 5. Fix

- Easy fix → just do it.
- Large breaking change → stop and ask before rewriting.
- Something broke → check whether the *old* version broke too before blaming the update.
  Pre-existing breakage is a separate report, not a fix.

## 6. Report

Short and concise, no jargon, no changelog dumps. Only:

- What was upgraded - majors and anything notable
- What you fixed and why
- What is blocked, held back, or needs a decision
- New features worth adopting: what it does and how this project would use it