version-upgrade — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited version-upgrade (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Upgrading a package without research is how green CI and broken production happen. The target version may rename APIs, drop Node support, change defaults, or break peers you didn't know you had.
This skill is the research → impact → fix → verify loop for one package (or a tight group) at a time. Search the web and read official docs before changing versions — don't guess from semver alone.
Pairs with [[dependency-hygiene]] for vetting and cadence, [[migration-path]] when the upgrade breaks internal or external callers, [[source-first]] to verify APIs against real docs, [[test-first]] and [[browser-checks]] to prove behavior, [[fault-recovery]] when the upgrade fails mid-way, and [[decision-docs]] for major framework jumps.
Run the version upgrade checklist and capture findings in the PR description.
npm install / pnpm installSkip as primary skill for adding a brand-new dependency (use [[dependency-hygiene]] vetting). Not a substitute for [[migration-path]] when your API/schema changes — version-upgrade is for vendor release notes and code fixes in your repo.
| Situation | Lead skill |
|---|---|
| Should we add this package? | [[dependency-hygiene]] |
| Upgrade React 18 → 19, Next 14 → 15 | version-upgrade |
| Our REST API v1 → v2 for consumers | [[migration-path]] |
| CVE patch, same major | version-upgrade (lighter pass) |
One package (or one logical stack) per branch. Do not upgrade unrelated deps in the same PR.
Record before any search:
| Field | Example |
|---|---|
| Package | next |
| Ecosystem | npm / pnpm / yarn / pip / cargo / go / maven / nuget |
| Current resolved version | 14.2.3 (from lockfile, not range) |
| Target version | 15.1.0 |
| Reason | features, CVE, EOL, peer requirement |
Read the lockfile for the resolved version — package.json ranges lie.
Do not skip this step. Use web search and fetch official sources until you have concrete notes.
Search queries (adapt to package):
{package} {current} to {target} migration guide
{package} {target} release notes breaking changes
{package} {target} changelog
{package} upgrade guide site:github.com OR site:{official-docs-domain}Sources to read (in priority order):
node, python), deprecated subpathsCapture in upgrade notes:
| Version | New features (relevant to us) | Breaking / behavior changes | Deprecations |
|---|---|---|---|
| x.y.z | … | … | … |
If no migration guide exists: read CHANGELOG entry-by-entry from current+1 through target.
Inventory your usage before editing:
# Examples — adapt to ecosystem
rg "from ['\"]next" --type ts
rg "require\\(['\"]next"
grep -r "package-name" . --include="*.ts" --include="*.tsx" --include="*.js"For each breaking change from step 2, mark:
| Breaking change | Affected files / config | Fix strategy | Risk |
|---|---|---|---|
Removed API foo() | src/lib/bar.ts:12 | Replace with baz() per docs | Medium |
Also check:
next.config.js, vite.config.ts, tsconfig, eslint.config, CI workflowsIf the blast radius is wide or external consumers break, escalate to [[migration-path]].
Order matters when peers are coupled:
@types/*npx @next/codemod, etc.)Prefer one logical upgrade PR when peers must align; split only when bisect needs clear boundaries.
Document rollback: previous lockfile hash or git revert path; feature flags if behavior change is risky.
# npm example — use ecosystem equivalent
npm install package@target --save-exact # or save-dev; prefer lockfile update
npm ci && npm run build && npm testRules:
any unless documented temporary — fix the API usage| Change type | Fix approach |
|---|---|
| Renamed export | Update imports; check subpath exports changed |
| Removed API | Replace per migration guide; don't polyfill vendor internals |
| Changed default behavior | Opt out via config if supported; else update tests and product |
| Stricter types | Fix types at call sites; avoid @ts-ignore without ticket |
| Dropped Node/browser version | Update engines, CI, Docker, .nvmrc |
| Config key renamed | Map old → new in config; grep for old key in repo |
| Peer dependency warning | Upgrade peer or use supported version matrix from docs |
Re-run web search for specific error messages if stuck — include package name and version in query.
Minimum before merge:
npm ci, frozen lock)For majors: staged deploy or canary when behavior defaults changed ([[launch-readiness]]).
PR description template:
## Upgrade: {package} {current} → {target}
### Why
- …
### New features we use (optional)
- …
### Breaking changes addressed
| Change | Fix |
|--------|-----|
| … | … |
### Research links
- [Migration guide](…)
- [Release notes](…)
### Verification
- [ ] CI green on clean install
- [ ] …Major framework upgrades: optional ADR ([[decision-docs]]).
npm install and hope@ts-expect-error / --legacy-peer-deps without documented reason~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.