Help us improve
Share bugs, ideas, or general feedback.
From ai-kit
Audits and updates Node.js dependencies using native package-manager commands (npm, pnpm, yarn, bun). Applies patches silently, asks before minor, confirms each major, and cross-checks changelogs and security advisories.
npx claudepluginhub ivklgn/ai-kitHow this skill is triggered — by the user, by Claude, or both
Slash command
/ai-kit:update-node-depssonnetThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Audit and update Node.js project dependencies safely, one semver tier at a time. Use native package-manager commands only — no `npm-check-updates` or other third-party wrappers.
Audits npm dependencies for security vulnerabilities, freshness, and bundle impact. Use when responding to CVEs, upgrading packages, or reviewing dependency health.
Detects package managers (npm/yarn/pnpm, pip/uv, cargo, go, bundler), audits dependencies for outdated versions and vulnerabilities, and generates prioritized update plans with major version risk analysis.
Share bugs, ideas, or general feedback.
Audit and update Node.js project dependencies safely, one semver tier at a time. Use native package-manager commands only — no npm-check-updates or other third-party wrappers.
Determine the PM in this order (stop at first match):
packageManager field in package.json (corepack convention: "pnpm@9.x", "yarn@4.x", etc.).pnpm-lock.yaml → pnpmyarn.lock → yarn (detect classic vs berry via .yarnrc.yml presence or yarn --version)bun.lockb or bun.lock → bunpackage-lock.json → npmpackageManager field, default to npm and note it.Read the matching reference file for exact native commands — do not hardcode them in this workflow:
Check for: workspaces array in root package.json, pnpm-workspace.yaml, turbo.json, nx.json, or lerna.json.
If detected, ask the user whether to:
package.json onlyRun git status --porcelain -- package.json '*lock*'. If either package.json or the lockfile is dirty, warn the user — a dirty baseline makes tier rollback ambiguous. Ask whether to continue, stash, or abort.
Use the PM's native outdated command (from the reference file) with JSON output. Parse into rows:
{ name, current, wanted, latest, dependencyType }
Exclude packages using workspace: / catalog: / link: / file: / git+ protocols — these are local or pinned on purpose.
Run the PM's native audit command (from the reference file) in JSON mode. Record advisories keyed by package name, with severity (critical / high / moderate / low) and the fixed-in version.
For each outdated package, classify the jump from current to latest:
1.2.3 → 1.2.5 (same major.minor).1.2.3 → 1.3.0 (same major).1.2.3 → 2.0.0 (major bump).Pre-1.0 rule (enforce strictly — pre-1.0 libraries break often):
0.2.3 → 0.2.9 = patch0.2.3 → 0.3.0 = major (not minor — treat minor-in-zeromajor as breaking)0.2.3 → 1.0.0 = majorPatch changelogs are noise — skip them. For each minor and major update, fetch release notes in this order:
mcp__context7__resolve-library-id with the package namemcp__context7__query-docs with the resolved ID and query="changelog" (retry with query="releases" or query="breaking changes" if empty)gh:
npm view <pkg> repository.url --json 2>/dev/nullgh release view v<version> -R <owner>/<repo> (try with and without the v prefix)gh release list -R <owner>/<repo> --limit 10 to inspect multiple hopshttps://github.com/<owner>/<repo>/releases or https://www.npmjs.com/package/<pkg>Summarize each into one line: "Adds X. Deprecates Y. **Breaking:** Z." — keep breaking-change callouts prominent.
Apply in strict order: patch → minor → major. After each tier, run verification (Step 10) before proceeding to the next tier. If verification fails, offer rollback and stop.
Apply all patch updates and all security-fix updates (regardless of semver range) as one batch. Use the PM's batch patch-update command from the reference. Do not prompt. Report count after.
Present the full minor batch as a markdown table:
| Package | Current → Latest | Fixes advisory? | Changelog summary |
Ask the user: approve the batch, deselect specific packages, or skip tier entirely. Apply approved packages; report.
Iterate majors one at a time. For each:
current → latest@types/* jumps often come with API shifts)Ask per-package: apply / skip / defer-to-later. Apply each approved major individually, run install, then immediately run verification (Step 10). If verification fails for a specific major, offer rollback of just that package and continue to the next major.
Run after each tier (and after each individual major):
tsconfig.json exists: run npx tsc --noEmit (or the typecheck script if defined in package.json).scripts.build exists in package.json: run it via the PM.scripts.test exists: offer to run it (don't force — tests can be slow).On failure:
git checkout -- package.json <lockfile> then re-run the PM's install.Emit a concise markdown report:
# Node.js Dependencies Update Report
**Package manager:** pnpm (detected via pnpm-lock.yaml)
**Scope:** root (or workspace path)
## Applied
- patch: 12 packages (2 fixed advisories)
- minor: 5 packages (1 fixed advisory)
- major: 2 packages
## Skipped / deferred
- `react@19.0.0` — deferred, needs app-wide migration review
- `eslint@9.0.0` — skipped, flat-config migration blocker
## Security advisories
- Resolved: 3 (HIGH: 1, MODERATE: 2)
- Remaining: 1 (LOW — no fix available upstream)
## Verification
- install: ok
- typecheck: ok
- build: ok
- tests: not run (user declined)
--force or --legacy-peer-deps without explicit user approval. Peer-dep errors are signal, not noise.overrides / resolutions entries in package.json — they exist to pin problem versions; mention them in the report instead.workspace: / catalog: / link: / file: protocols — do not rewrite to literal versions.engines.node: if a major update's changelog says it requires a newer Node than engines.node, flag and skip.npm install in a pnpm project).