Use when raising the version of an INCOMING dependency. Fires on: "bump the dependency", "update the library", "upgrade <lib>", "refresh the lockfile", "dependencies are outdated". Bumps the version in the single source of truth, syncs the lockfile, rebuilds, revalidates, and fixes any pinned references.
SkillScore64Maintained
Automatic
◆Coding pack
Last verified 8/6/2026
What it changes
Passed 11 of 18 test cases with the skill, and 8 of 18 without it.
Without skill45%
With skill64%
Checks it passed that the model alone missed
Reports the exact failing assertion message in the summary.
Requires reporting the breaking assertion failures explicitly.
Specifies searching README badges, documentation, and .env example files.
and 1 more in the full report
4 fixed10 passed either way8 still failing0 broke
Pass-rate lift
+18 pp
Tokens
-22%
Agent turns
0%
Response time
-43%
Model gemini-3.6-flashMeasured 8/6/2026v114 of 22 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
While bumping Jackson in a Maven project from `2.15.2` to `2.16.1`, I noticed `testcontainers.version` is explicitly pinned to `1.18.0` in property tags with a comment 'deliberate compatibility override for local Docker daemon'. Should I automatically bump that property too?
What was checked, without and with the skill
Checked
Without skill
With skill
Advises against blindly upgrading load-bearing or deliberate version pins.
Passed
Passed
Requires explicit confirmation before modifying intentionally pinned properties.
Missed
Passed
case-06 · gemini-3.6-flash · 8/6/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md27 linessingle file
bump-deps — one version, propagated to every pin
A dependency version usually lives in more than one place. Bump the source of
truth, then chase every pin — a half-bumped dependency is drift that compiles.
Procedure
Identify the SSOT: the manifest that declares the version — e.g.
pom.xml dependency management, pyproject.toml, package.json. Bump there.
Sync the lockfile: regenerate the lock so it matches (uv lock,
npm install, etc.). Lockfile and manifest must move together — CI likely
runs --locked / --frozen and will fail otherwise.
Chase pinned references: grep for the old version string in scripts,
Dockerfiles, docs, .env examples, README badges — bump each. Consult
.skills/change-map.yaml if a "new dependency" coupling is listed.
Respect load-bearing pins: some pins are intentional (a BOM, a
Testcontainers version). Do not "upgrade" those blindly — confirm before
touching a pin the project marks as deliberate.
Rebuild + revalidate: run the build and the relevant tests / golden lane.
A dependency bump is not done until the suite is green.
Report breaking changes: if the bump pulled a breaking transitive change,
surface it — do not silently paper over it.
Output
Old → new version, every file touched, build/test result. If the build breaks,
report the failing assertion — do not leave a half-applied bump.