Can I use web search to confirm latest versions?

Yes, if allowed; otherwise rely on registry lookups (npm, Maven Central, Gradle Plugin Portal).

What if tests fail after an upgrade?

Rollback, fix breakages, adjust the upgrade plan, and re-run tests; prefer incremental fixes.

How should breaking changes be documented?

Note changed versions, rationale, migrations, and any follow-ups or deprecations so future upgrades are smoother.

dependency-upgrader

Scanned

npx machina-cli add skill jmerta/codex-skills/dependency-upgrader --openclaw

Files (1)

SKILL.md

2.7 KB

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.
- If the required package manager or build tool is missing (npm/pnpm/yarn/bun, Gradle, Maven), tell the user and ask whether to install it or proceed with a manual edit-only upgrade.
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.

Source

git clone https://github.com/jmerta/codex-skills/blob/main/dependency-upgrader/SKILL.mdView on GitHub

Overview

Safely upgrade dependencies across Java/Kotlin (Gradle/Maven) and TypeScript/Node projects with minimal risk and reviewable diffs. The skill guides planning, incremental application, test/build verification, and clear documentation of breaking changes to keep systems stable.

How This Skill Works

Detects the project type and package manager, then records a baseline of current versions. Plans upgrades by risk, applies changes incrementally, and runs tests/build after each group. Finally, it documents what changed, why, and any breaking migrations.

When to Use It

When upgrading a single dependency or a grouped set (e.g., Spring Boot) with minimal risk.
When updating frameworks or plugins that require migration notes.
When addressing a CVE by upgrading vulnerable dependencies.
When coordinating upgrades across Java and Node ecosystems in one effort.
When you need a documented, reversible changelog of version bumps and migrations.

Quick Start

Step 1: Detect project type and baseline versions from dependency files and lockfiles.
Step 2: Plan upgrades by risk, select target versions, and group changes.
Step 3: Apply upgrades group-by-group, running tests after each step and documenting results.

Best Practices

Baseline first: capture current versions and run the repo's smallest reliable test/build.
Plan upgrades in small groups, starting with low-risk patches/minors.
Confirm target versions against official release notes and registries.
After each group, run tests/build and fix breakages immediately.
Document changes, migrations, deprecations, and any follow-ups for future work.

Example Use Cases

Maven project upgrading Spring Boot 2.x to 3.x with migration notes.
Node project patching dependencies to address a CVE while keeping builds green.
Gradle wrapper and plugin upgrades across a multi-module project with CI validation.
NPM/Node upgrade in a monorepo, ensuring dependent packages compile and tests pass.
Cross-language upgrade in a mono-repo with JS and JVM modules, with explicit breaking changes documented.

Frequently Asked Questions

Add this skill to your agents