dependency-upgrader
Upgrade dependencies for Java/Kotlin (Gradle/Maven) and TypeScript/Node projects with minimal risk: plan the bump, apply changes incrementally, run tests/builds, and document breaking changes. Use when the user asks to bump deps, update frameworks, or address CVEs.
When & Why to Use This Skill
The Dependency Upgrader is a specialized Claude skill designed to automate the complex process of updating software libraries in Java, Kotlin, TypeScript, and Node.js projects. It minimizes regression risks by incrementally applying changes, verifying builds via Gradle, Maven, or npm/pnpm/yarn, and documenting breaking changes. This tool is essential for maintaining project health, ensuring security compliance through CVE fixes, and streamlining framework migrations with minimal manual intervention.
Use Cases
- Automated Security Patching: Quickly address critical CVEs by identifying vulnerable dependencies and upgrading them to the latest secure versions while verifying build stability.
- Routine Maintenance: Perform scheduled minor and patch version bumps across large monorepos or microservices to stay current with the latest features and bug fixes.
- Major Framework Migrations: Manage high-risk upgrades, such as moving to a new major version of Spring Boot or Node.js, by analyzing migration guides and handling breaking changes incrementally.
- Technical Debt Reduction: Clean up outdated libraries and synchronize dependency versions across multi-module projects to ensure environment consistency and reduce build errors.
| name | dependency-upgrader |
|---|---|
| description | "Upgrade dependencies for Java/Kotlin (Gradle/Maven) and TypeScript/Node projects with minimal risk: plan the bump, apply changes incrementally, run tests/builds, and document breaking changes. Use when the user asks to bump deps, update frameworks, or address CVEs." |
Dependency upgrader
Goal
Safely upgrade dependencies with minimal, reviewable diffs and clear verification.
Inputs to ask for (if missing)
- Which ecosystem: Gradle/Maven, Node/TypeScript, or both.
- Scope: one dependency, a set (e.g., Spring Boot), or "everything".
- Constraints: patch/minor only vs allow majors; time budget; CI requirements.
- Motivation: CVE fix, feature need, or routine maintenance.
- Can the agent use web search to confirm latest versions and read migration notes? (If not, rely on registry lookups.)
Workflow (checklist)
- Detect the project type and package manager
- Node:
package.json+ lock file (pnpm-lock.yaml,package-lock.json,yarn.lock,bun.lock). - Gradle:
gradlew,build.gradle(.kts),settings.gradle(.kts),gradle/libs.versions.toml. - Maven:
pom.xml.
- Node:
- Establish a baseline
- Record current versions (dependency file + lock files).
- Run the smallest reliable test/build command the repo uses (then expand if needed).
- Plan the upgrade
- Prefer the smallest bump that solves the problem.
- Choose target versions using up-to-date sources:
- Use web search (if available) to confirm latest stable versions and skim official release notes/migration guides.
- Cross-check with the registry/source of truth (npm registry, Maven Central, Gradle Plugin Portal).
- Group by risk:
- low: patches/minors, leaf deps
- medium: build tools/plugins
- high: framework majors (Spring Boot), runtime bumps (Java/Node)
- For majors: skim upstream migration notes and list expected breakpoints before editing.
- Apply upgrades incrementally
- Update one group at a time; keep diffs focused.
- After each group: run tests/build and fix breakages immediately.
- Use the playbooks in
references/for ecosystem-specific commands.
- Validate and document
- Run the repo's "CI equivalent" commands (tests + build).
- Document:
- what changed (versions)
- why (CVE, compatibility, feature)
- notable migrations or breaking changes
- any follow-ups (deprecations, future majors)
Deliverable
Provide:
- The list of version bumps (old -> new).
- The commands run and their result (tests/build).
- Any breaking changes and required code/config migrations.