brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
absolute-upgradeDependency 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 dependencies", "bump deps", "update packages", "move off the deprecated X", "clear the De…
Independent GitHub snapshot · Automated classification · Original documentation governs
name: absolute-upgrade version: 0.5.0 description: > 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 dependencies", "bump deps", "update packages", "move off the deprecated X", "clear the Dependabot backlog". category: workflow tags:
Start your first response with the ⬆️ emoji.
Bring dependencies current — safely, in risk-ranked waves, with tests green after each.
Not a blind npm update: outdated and vulnerable deps are grouped by blast radius
(patch/minor → safe wave; major/breaking → gated, one at a time, changelog-read), applied
incrementally, and verified against the project's own test suite.
Runs the shared engine in references/health-engine.md — read it for the
DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT loop and the safety contract. This file
covers only what's specific to dependency upgrades.
npm outdated / Dependabot backlog without 40 separate PRs.Not for: adding a new dependency (that's a work/feature decision), or auditing
vulnerabilities specifically → use /absolute audit (it triages CVEs; upgrade
moves versions).
Per ecosystem, list outdated deps with current → wanted → latest and the jump type:
| Ecosystem | Detect outdated | Lockfile / manifest |
|---|---|---|
| npm | npm outdated --json | package-lock.json |
| pnpm | pnpm outdated --format json | pnpm-lock.yaml |
| yarn | yarn outdated --json | yarn.lock |
| Python (pip) | pip list --outdated --format=json | requirements*.txt |
| Python (poetry/uv) | poetry show --outdated / uv pip list --outdated | pyproject.toml + lock |
| Go | go list -u -m -json all | go.mod / go.sum |
Also flag: deps with known deprecations, duplicate/multiple versions of the same package, and direct vs transitive (only direct deps are upgrade targets; transitives follow).
Group the upgrade plan into waves by semver jump — safest first:
| Wave | Jump | Default |
|---|---|---|
| 1 | patch (x.y.Z) | batch together, fix now |
| 2 | minor (x.Y.z) | batch by package family, fix now |
| 3 | major (X.y.z) / pre-1.0 minor | one at a time, gated — read the changelog/migration guide first, list breaking changes |
For every major bump: locate breaking changes (CHANGELOG, release notes, codemod if the package ships one), inventory call sites that touch the changed API, and state the migration before applying. Peer-dependency conflicts get resolved in the same wave as their driver.
--force / --legacy-peer-deps to mask a real conflict.npm install succeeding proves nothing — run tests./absolute audit — if the goal is fixing vulnerabilities, start there; it'll route
back here for the version moves./absolute deflake — flaky tests can mask whether an upgrade truly passed./absolute work — if an upgrade needs real feature-level migration work, hand off.