Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →platformplatform/upgrade-packages
Upgrade all backend (.NET/NuGet), frontend (npm), and GitHub Actions dependencies to their latest versions, in that fixed order. Drives the developer CLI's update-packages command, parses its quiet dry-run output to separate trivial bumps from majors, ships trivial bumps as one bulk commit per side, and gives every major (and any code/config change) its own clean commit. Detects required toolchain installs (e.g. a new .NET SDK that needs sudo) and asks the user to run them up front so the backen
Passed 14 of 19 test cases with the skill, and 6 of 19 without it.
and 7 more in the full report
10 fixed6 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
During the backend package dry-run, the CLI reports that a required .NET SDK version is not installed on the system. What exact action should be taken next?
| Checked | Without skill | With skill |
|---|---|---|
| Requests the user to run the specific SDK installer command with elevated privileges and waits for confirmation | Missed | Passed |
The instructions your model reads when the skill loads.
Bring all backend, frontend, and GitHub Actions dependencies to their latest versions. The project always runs the latest version of every package. Don't quit, give up, or recommend reverting just because something is non-trivial — research, debug, push through. The only acceptable reasons to skip an upgrade are the permanent exceptions below.
Every NuGet and npm bump goes through the developer CLI. Run it directly (the Bash hook allows dotnet run --project developer-cli, and the CLI runs its own dotnet/npm subprocesses without tripping the hook):
dotnet run --project developer-cli -- update-packages [--backend|--frontend] [--dry-run] [--exclude <csv>] [--include-major-framework-updates] --quiet
Always pass --quiet. In quiet mode the command prints no tables or banners — only parseable plain-text lines:
<side> <patch|minor|major> <package> <current> -> <new> [<extra>]
<side> restricted <package> <current> (latest <X> is a new major, pinned)
<side> excluded <package> <current>
summary <side> patch=<n> minor=<n> major=<n> excluded=<n> uptodate=<n>
<side> is backend or frontend. restricted lines are the permanent exceptions (pinned to their current major by the CLI). Use a --dry-run --quiet run to plan; parse the major lines to get the package names that need their own commit.
Run the build, format, lint, test, and e2e skills for all verification (never raw dotnet/npm).
These never move to a new major. The CLI enforces them itself (RestrictedNuGetPackages in developer-cli/Commands/UpdatePackagesCommand.cs), so you do not pass --exclude for them — they show up as restricted lines in the dry-run and are pinned to the latest version within their current major:
MediatR, FluentAssertions — later majors changed licensing/APIs.Microsoft.ApplicationInsights, Microsoft.ApplicationInsights.AspNetCore — the next major drops PageView tracking as part of moving to OpenTelemetry; the codebase uses PageView heavily and that migration is a separate effort.Note: frontend @microsoft/applicationinsights-* packages are not restricted and upgrade normally. .NET, Node.js, and @types/node stay within their current major unless you pass --include-major-framework-updates; don't cross a framework major as part of a routine package upgrade.
update-packages for every bump. Never hand-edit package.json / Directory.Packages.props or run raw npm / dotnet to move a version.developer-cli/Commands/UpdatePackagesCommand.cs, and commit that fix on its own. Working around a CLI bug by hand is unacceptable — the next person deserves the fix.test cases passed, vs 6 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.