Agent skill — safe dependency upgrades

The MCP server gives an agent the data — available upgrades, risk levels, release-by-release breaking changes. This skill gives it the judgement: a tested playbook for turning that data into safe, reviewable upgrade PRs. It encodes the order of operations (security first, majors last), when to read release details before acting, when green tests can't be trusted, and how to leave the upgrade list clean for the next session.

Download #

For Claude Code, install it into the repository so every session (including web sessions) picks it up automatically:

mkdir -p .claude/skills/devupdate-dependency-upgrades
curl -o .claude/skills/devupdate-dependency-upgrades/SKILL.md \
  https://devupdate.io/skills/devupdate-dependency-upgrades/SKILL.md

Commit the file. Claude Code loads skills from .claude/skills/ and invokes this one whenever someone asks it to upgrade dependencies. Personal rather than per-repo? Put it in ~/.claude/skills/ instead.

For other clients (Cursor, claude.ai, custom agents), paste the file's contents into the system prompt or project instructions — it's plain markdown with no Claude-specific syntax beyond the frontmatter.

The skill assumes the MCP server is connected; set that up first.

What the skill encodes #

The short version of the playbook:

1. Triage with get_lockfile_upgrade_summary — which lockfiles need attention, and how many dependencies aren't monitored at all.
2. Pull everything, unfiltered, with get_available_upgrades. A filtered query that returns nothing is not "up to date".
3. Partition into waves: critical (security in range) first, then a low/medium batch, then each high (major/breaking) upgrade decided individually.
4. Read the range before risky upgrades with get_upgrade_details — the release-by-release breaking changes, security fixes, and migration notes between the pinned and latest version. This is also where the skill tells the agent that green tests prove nothing when the dependency is mocked in the suite.
5. Apply with native tooling (uv lock --upgrade-package, npm update, cargo update -p, …), respecting coupled pins like aiobotocore ↔ botocore.
6. Verify with the project's tests, lint, and typecheck — bisecting within a wave on failure.
7. Close the loop: taken upgrades auto-resolve on the next sync; deliberately deferred ones get dismiss_upgrades so the next session starts clean; not monitored dependencies get a native registry audit (npm audit, pip-audit) since DevUpdate.io has no data for them.
8. Report what was taken, deferred (and why), and what's out of scope.

Why a skill and not just the tools? #

Tool descriptions travel with every request, so they stay terse. The playbook above is the opposite: it's long, opinionated, and only needed when the agent is actually doing upgrade work. Shipping it as a skill means the agent loads it exactly then — and you can edit your copy to match how your team works (pin Node majors, never auto-take database drivers, whatever your rules are). It's your file once you download it.