absolute-upgrade

Name: absolute-upgrade
Author: maddhruv

24installs32forks

How to install absolute-upgrade?

maddhruv/absolute/absolute-upgrade

$npx -y skills add maddhruv/absolute --skill absolute-upgrade

Installs into the current project.

Summary

Dependency upgrades: outdated/vulnerable deps planned into semver waves (patch/minor batched, majors gated and changelog-read), applied incrementally with lockfiles regenerated and tests green after each. Runs on green main. Triggers on "absolute upgrade", "upgrade our dependenci

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the ⬆️ emoji.
2
3	## Absolute Upgrade
4
5	Bring dependencies current — safely, in risk-ranked waves, with tests green after each.
6	Not a blind `npm update`: outdated and vulnerable deps are grouped by blast radius
7	(patch/minor → safe wave; major/breaking → gated, one at a time, changelog-read), applied
8	incrementally, and verified against the project's own test suite.
9
10	Runs the shared engine in `references/health-engine.md` — read it for the
11	DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT loop and the safety contract. This file
12	covers only what's specific to dependency upgrades.
13
14	---
15
16	## When to use
17
18	- Routine "bring deps up to date" / "upgrade our dependencies".
19	- A specific bump: "upgrade React to 19", "move off the deprecated X package".
20	- Clearing `npm outdated` / Dependabot backlog without 40 separate PRs.
21
22	Not for: adding a new dependency (that's a `work`/feature decision), or auditing
23	vulnerabilities specifically → use `/absolute audit` (it triages CVEs; `upgrade`
24	moves versions).
25
26	---
27
28	## What it scans
29
30	Per ecosystem, list outdated deps with current → wanted → latest and the jump type:
31
32	\| Ecosystem \| Detect outdated \| Lockfile / manifest \|
33	\|---\|---\|---\|
34	\| npm \| `npm outdated --json` \| `package-lock.json` \|
35	\| pnpm \| `pnpm outdated --format json` \| `pnpm-lock.yaml` \|
36	\| yarn \| `yarn outdated --json` \| `yarn.lock` \|
37	\| Python (pip) \| `pip list --outdated --format=json` \| `requirements*.txt` \|
38	\| Python (poetry/uv) \| `poetry show --outdated` / `uv pip list --outdated` \| `pyproject.toml` + lock \|
39	\| Go \| `go list -u -m -json all` \| `go.mod` / `go.sum` \|
40
41	Also flag: deps with known deprecations, duplicate/multiple versions of the same package,
42	and direct vs transitive (only direct deps are upgrade targets; transitives follow).
43
44	---
45
46	## Risk ranking (TRIAGE)
47
48	Group the upgrade plan into waves by semver jump — safest first:
49
50	\| Wave \| Jump \| Default \|
51	\|---\|---\|---\|
52	\| 1 \| patch (`x.y.Z`) \| batch together, fix now \|
53	\| 2 \| minor (`x.Y.z`) \| batch by package family, fix now \|
54	\| 3 \| major (`X.y.z`) / pre-1.0 minor \| one at a time, gated — read the changelog/migration guide first, list breaking changes \|
55
56	For every major bump: locate breaking changes (CHANGELOG, release notes, codemod if the
57	package ships one), inventory call sites that touch the changed API, and state the
58	migration before applying. Peer-dependency conflicts get resolved in the same wave as
59	their driver.
60
61	---
62
63	## Fix & verify
64
65	- Apply a wave, regenerate the lockfile, run the project's full test + build (a passing
66	install is not a passing upgrade).
67	- Majors: apply the version bump and the required code migration in the same wave, or the
68	build breaks. Use the package's codemod where one exists.
69	- A wave that can't go green within reason → revert it, report it as blocked with the error,
70	keep the green waves. Never `--force` / `--legacy-peer-deps` to mask a real conflict.
71
72	---
73
74	## Gotchas
75
76	1. Lockfile-only "upgrade". Bumping the manifest without regenerating + committing the
77	lockfile ships untested transitive versions. Always regenerate.
78	2. Batching a major in with patches. One breaking bump fails the whole wave and hides
79	which change broke it. Majors are always solo.
80	3. Green install ≠ green project. `npm install` succeeding proves nothing — run tests.
81	4. Pinning around a failure. If a bump breaks something, fix or defer it; don't pin the
82	dependency tree to dodge it silently.
83
84	---
85
86	## Companion commands
87
88	- `/absolute audit` — if the goal is fixing vulnerabilities, start there; it'll route
89	back here for the version moves.
90	- `/absolute deflake` — flaky tests can mask whether an upgrade truly passed.
91	- `/absolute work` — if an upgrade needs real feature-level migration work, hand off.

People who liked this also viewed

6 picks

Type

absolute-upgrade

24installs32forks

View on GitHub

How to install absolute-upgrade?

maddhruv/absolute/absolute-upgrade

$npx -y skills add maddhruv/absolute --skill absolute-upgrade

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the ⬆️ emoji.
2
3	## Absolute Upgrade
4
5	Bring dependencies current — safely, in risk-ranked waves, with tests green after each.
6	Not a blind `npm update`: outdated and vulnerable deps are grouped by blast radius
7	(patch/minor → safe wave; major/breaking → gated, one at a time, changelog-read), applied
8	incrementally, and verified against the project's own test suite.
9
10	Runs the shared engine in `references/health-engine.md` — read it for the
11	DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT loop and the safety contract. This file
12	covers only what's specific to dependency upgrades.
13
14	---
15
16	## When to use
17
18	- Routine "bring deps up to date" / "upgrade our dependencies".
19	- A specific bump: "upgrade React to 19", "move off the deprecated X package".
20	- Clearing `npm outdated` / Dependabot backlog without 40 separate PRs.
21
22	Not for: adding a new dependency (that's a `work`/feature decision), or auditing
23	vulnerabilities specifically → use `/absolute audit` (it triages CVEs; `upgrade`
24	moves versions).
25
26	---
27
28	## What it scans
29
30	Per ecosystem, list outdated deps with current → wanted → latest and the jump type:
31
32	\| Ecosystem \| Detect outdated \| Lockfile / manifest \|
33	\|---\|---\|---\|
34	\| npm \| `npm outdated --json` \| `package-lock.json` \|
35	\| pnpm \| `pnpm outdated --format json` \| `pnpm-lock.yaml` \|
36	\| yarn \| `yarn outdated --json` \| `yarn.lock` \|
37	\| Python (pip) \| `pip list --outdated --format=json` \| `requirements*.txt` \|
38	\| Python (poetry/uv) \| `poetry show --outdated` / `uv pip list --outdated` \| `pyproject.toml` + lock \|
39	\| Go \| `go list -u -m -json all` \| `go.mod` / `go.sum` \|
40
41	Also flag: deps with known deprecations, duplicate/multiple versions of the same package,
42	and direct vs transitive (only direct deps are upgrade targets; transitives follow).
43
44	---
45
46	## Risk ranking (TRIAGE)
47
48	Group the upgrade plan into waves by semver jump — safest first:
49
50	\| Wave \| Jump \| Default \|
51	\|---\|---\|---\|
52	\| 1 \| patch (`x.y.Z`) \| batch together, fix now \|
53	\| 2 \| minor (`x.Y.z`) \| batch by package family, fix now \|
54	\| 3 \| major (`X.y.z`) / pre-1.0 minor \| one at a time, gated — read the changelog/migration guide first, list breaking changes \|
55
56	For every major bump: locate breaking changes (CHANGELOG, release notes, codemod if the
57	package ships one), inventory call sites that touch the changed API, and state the
58	migration before applying. Peer-dependency conflicts get resolved in the same wave as
59	their driver.
60
61	---
62
63	## Fix & verify
64
65	- Apply a wave, regenerate the lockfile, run the project's full test + build (a passing
66	install is not a passing upgrade).
67	- Majors: apply the version bump and the required code migration in the same wave, or the
68	build breaks. Use the package's codemod where one exists.
69	- A wave that can't go green within reason → revert it, report it as blocked with the error,
70	keep the green waves. Never `--force` / `--legacy-peer-deps` to mask a real conflict.
71
72	---
73
74	## Gotchas
75
76	1. Lockfile-only "upgrade". Bumping the manifest without regenerating + committing the
77	lockfile ships untested transitive versions. Always regenerate.
78	2. Batching a major in with patches. One breaking bump fails the whole wave and hides
79	which change broke it. Majors are always solo.
80	3. Green install ≠ green project. `npm install` succeeding proves nothing — run tests.
81	4. Pinning around a failure. If a bump breaks something, fix or defer it; don't pin the
82	dependency tree to dodge it silently.
83
84	---
85
86	## Companion commands
87
88	- `/absolute audit` — if the goal is fixing vulnerabilities, start there; it'll route
89	back here for the version moves.
90	- `/absolute deflake` — flaky tests can mask whether an upgrade truly passed.
91	- `/absolute work` — if an upgrade needs real feature-level migration work, hand off.

People who liked this also viewed

6 picks

Type