Vp deps upgrade
Reusable Agent Skills by VdustR
npx -y skills add VdustR/skills --skill vp-deps-upgradeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Upgrade dependencies with breaking change detection and migration planning. Use when asked to "upgrade dependencies", "update packages", "bump dependencies", "bump <package> to <version>", "update <package> to version <version>", "handle dependabot PR", "handle renovate PR", "check for breaking changes", "upgrade <package> to <version>", "check outdated dependencies", "scan for updates", or when reviewing dependency bot PRs (dependabot, renovate, GitHub Actions), or when addressing security alerts, CVE notices, or vulnerability patches. Also trigger when the user mentions outdated packages, version bumps, or package manager update commands. Boundary: for version bumps within the same library. Use vp-deps-migrate when replacing one library with another.
SKILL.md
9.4 KB, as published. Nobody here has run it
Dependency Upgrade
Upgrade dependencies with breaking change detection, test-first verification, and repo convention compliance.
Workflow
Non-linear execution: Phases are numbered for reference, not strict order. If findings in any phase invalidate earlier assumptions, restart from the affected phase.
Phase 1: Environment Analysis
- Detect package manager from lockfile (see package-managers.md)
- Detect monorepo structure (workspaces, pnpm-workspace.yaml)
- Detect CI, hooks, changeset config (see repo-conventions.md)
Phase 2: Identify Upgrade Target
Three entry paths:
- A) User specifies package + version
- B) Bot PR → parse from PR title/body/diff (see deps-bot-handling.md)
- C) Bulk scan → run outdated command, present results
Determine update type:
| Type | Detection | Risk |
|---|---|---|
| Lockfile-only | New version within existing range | Low |
| Range update (minor) | Range change required, minor bump | Medium |
| Range update (major) | Range change required, major bump | High |
Phase 3: Documentation & Breaking Changes Analysis
Consult all sources (use subagents for parallel lookup when possible, not a fallback chain):
- Context7 →
resolve-library-id+query-docsfor migration guides (see context7-integration.md) - Changelog/releases → Parse CHANGELOG.md +
gh api repos/{owner}/{repo}/releases - Code changes → Analyze source code diffs for hidden breaking changes
Combine into a breaking changes report: High/Medium/Low impact, affected files (grep for deprecated APIs), migration action for each change. Conflict resolution: If sources disagree, use the most conservative (highest risk) conclusion and flag the discrepancy in the report.
Phase 3.5: Official Tools & Compat Layer Detection
Check for official/community migration tools before writing custom migrations:
| Source | What to look for | Example |
|---|---|---|
| Migration guide | Codemod CLI commands | npx react-codemod rename-unsafe-lifecycles |
| npm registry | *-codemod packages | @next/codemod, react-codemod |
| Target docs | Compat layer | es-toolkit/compat (lodash compatible) |
| Framework CLI | Auto-migration scripts | npx @angular/cli update |
Decision flow:
- Codemod exists → run codemod first, handle remaining manually
- Compat layer available → ask user: gradual (compat) or full replacement?
- Neither → proceed to Phase 4 (manual migration)
Phase 3.7: Related Package Detection
Detect packages that must be co-upgraded:
| Pattern | Detection | Example |
|---|---|---|
@types/ packages | Check devDeps for @types/<pkg> | react → @types/react |
Scoped @types/ | @scope/pkg → @types/scope__pkg | @babel/core → @types/babel__core |
| Peer dep ecosystem | Parse peerDependencies | react → react-dom |
| Peer dep types | For each peer dep found above, also check for @types/<peer> | react-dom → @types/react-dom |
| Framework integration | Known ecosystem groups | next requires compatible react |
| Workspace refs | workspace:* — skip (local) | — |
Present related packages to user and ask whether to include in upgrade plan.
Phase 4: Test-First Verification
Validate the migration approach before batch execution.
Quick feasibility check: If migration is config-only (e.g., ESLint flat config) or requires extensive project context, skip /tmp and go directly to subagent review.
If /tmp verification is feasible:
- Scan all usage — grep/glob for all imports, API calls, type references
- Write test diffs in /tmp — create isolated test files:
Environment setup: Create a minimal/tmp/deps-shift-verify-<package>-<timestamp>/ ├── package.json # Minimal deps (target package only) ├── tsconfig.json # Copied from project, paths/aliases adjusted for /tmp ├── original/ # Copy of affected code snippets ├── migrated/ # Proposed migration applied └── test-runner.sh # Must run tsc --noEmit at minimum, must NOT be just exit 0package.json, install only the target package version fresh. Copy project'stsconfig.json; removepaths,baseUrl, andreferencesfields that point to project-specific locations — /tmp resolves modules through its ownnode_modulesonly. Never mutate the project's actualnode_modules. - Run verification — type check + unit tests on migrated snippets
- Pass → proceed to Phase 5
- Fail → iterate (max 3 attempts), then present failure analysis to user
Fallback: When tests can't be written → subagent 3-pass review loop:
- Pass 1 (Direct): correctness — syntax, imports, types
- Pass 2 (Best Practice): idiomatic usage, recommended patterns
- Pass 3 (Critical Think): edge cases, hidden behavioral changes
- Fix + loop until all passes clean
Phase 5: Migration Plan & Confidence Index
Present structured plan with confidence index:
- Steps to execute (informed by Phase 4 results)
- Estimated impact (files, breaking changes count)
- Confidence index with factor breakdown and boost options
- Repo convention actions (changeset, commit format)
Always get user confirmation before executing.
Phase 6: Execute Migration
- Update dependency versions via package manager (including related packages from Phase 3.7)
- Install (update lockfile)
- Check for peer dependency conflicts — if install warns, present options in priority order: (a) upgrade conflicting package — preferred, (b) abort — if no compatible version exists yet, (c)
--legacy-peer-deps— last resort; warn user this bypasses peer validation and may cause runtime issues - Apply code migrations (using verified approach from Phase 4)
- For bot PRs: checkout PR branch, apply migrations, push
- Clean up /tmp verification files
Phase 7: Repo Convention Compliance
Detect and follow project conventions (see repo-conventions.md):
- Changesets → create changeset file
- Conventional commits → follow format
- CI checks → run matching local commands
- Pre-commit hooks → ensure hooks pass
- Custom scripts → run test, lint, typecheck
Phase 8: Final Verification
- Type check → 2. Lint → 3. Test suite → 4. Build
- For complex migrations: run subagent Pass 3 (Critical Think) as final quality gate
- All pass → report success
- Failures → analyze if upgrade-related, attempt fix, present remaining to user
- Bot PR → push + check CI via
gh pr checks. Never auto-merge just because CI passes — confirm the breaking changes report is fully addressed first
Error Handling
| Error | Action |
|---|---|
| Package manager command fails | Check lockfile integrity, suggest rm -rf node_modules && install |
| Changelog/releases API 404 | Fall back to source code diff analysis |
| Codemod crashes partway | Report progress, show which files were transformed, suggest manual completion |
| Context7 MCP tool not found | Suggest installation, continue with changelog + releases + code analysis |
| Monorepo workspace resolution fails | Ask user to specify target package(s) |
| Tests still fail after 3 iterations | Present failure analysis, ask user how to proceed |
| /tmp write fails | Fall back to subagent review |
Reference Files
- package-managers.md — Detection matrix and commands
- repo-conventions.md — Convention detection and compliance
- confidence-index.md — Confidence index specification
- context7-integration.md — Context7 MCP detection and usage
- deps-bot-handling.md — Dependabot and Renovate PR handling
Notes
- Requirements:
ghCLI (for bot PRs, releases API), package manager CLI - Context7: Optional but recommended; install through the current agent's MCP or tool setup flow.
- Supported ecosystems: npm, pnpm, yarn, bun, cargo, pip/uv/poetry, go, bundler, composer
- Limitations: Private registry auth requires manual setup; no auto-handling of 2FA prompts
- Monorepos: Detected automatically, but user may need to specify target package for large workspaces
- Boundary: When a major upgrade (e.g., React 18→19) requires API migration, this skill handles it. Use
vp-deps-migrateonly when the primary intent is replacing one library with another.