---
name: dependency-upgrade-plan
description: "Sequences a set of dependency upgrades from safest to riskiest, summarises the breaking changes in each, and defines the checks to pass before moving on. Use when a project has several outdated packages and needs an ordered upgrade plan with breaking changes and checks per step. Do not use for resolving a single failing install or auditing packages for security issues. Related topics: coding, devops."
---

# Dependency Upgrade Plan

Sequences a set of dependency upgrades from safest to riskiest, summarises the breaking changes in each, and defines the checks to pass before moving on.

## When to use

Use this skill when a project has several outdated packages and needs an ordered upgrade plan with breaking changes and checks per step. Do not use it for resolving a single failing install or auditing packages for security issues.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Group the packages by how they depend on each other and mark which are runtime, build or leaf packages.
3. Order the upgrades with foundations first and patch or minor bumps before majors, and justify any exception.
4. List the breaking changes for each major from the supplied notes and flag every claim that still needs verifying.
5. Define the checks after each step and the rollback point, matching the strength of the checks to the test coverage.
6. Split the work into pull requests by risk and name the first three actions to take today.

## Inputs

- **Dependencies and versions** (longer free text)
- **Project type** (free text, e.g. "Node API or Flutter app or Django site")
- **Test coverage** (choose one: Strong, Patchy, Almost none)
- **Deployment risk** (choose one: Internal tool, Customer facing, Revenue critical)
- **Release notes or changelogs** (longer free text)
- **Time available** (free text, e.g. "One afternoon or two sprints")

## Output

An ordered table of upgrade steps with packages, breaking changes, code areas affected, checks and rollback point, followed by a pull request grouping and the first three actions.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Dependency Upgrade Plan

Plan the upgrade of these dependencies.

- Dependencies and versions: {{Dependencies and versions}}
- Project type: {{Project type}}
- Test coverage: {{Test coverage}}
- Deployment risk: {{Deployment risk}}
- Release notes or changelogs: {{Release notes or changelogs}}
- Time available: {{Time available}}

Group the packages into those that depend on each other and those that stand alone. Order the upgrades so the foundations come first (runtime, language, build tool), then shared libraries, then leaf packages, and do patch and minor bumps before majors. For each major, list the breaking changes from the notes supplied, the code areas likely to feel them, and what to search for in the codebase. Mark anything you cannot confirm from the notes as a thing to verify, never as fact. After every step define the checks: install, build, tests, type checks, and one manual smoke test, with a clear rule for rolling back to the last good commit. Recommend one pull request per step for risky upgrades and a combined one for safe patches. Finish with the first three steps to do today.

## Pitfalls

- Upgrading everything at once, so a failing build cannot be traced to one package.
- Trusting remembered changelogs for a major version, which may be wrong or outdated for the exact target.
- Skipping the runtime or compiler version, which quietly blocks the later package upgrades.