just-vibeGeneral · inspect by default
/deps
Assess dependency updates and compatibility
Use for dependency assessment or requested updates; vite-upgrade handles Vite-specific migration behavior and security-fix remediates a confirmed advisory.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select deps from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv deps, /just-vibe deps and /jv:deps in Claude. See shortcut setup and context examples.
/just-vibe:deps Assess a compatible dependency update without changing files yet./just-vibe:deps Update one dependency with a conflicting peer and an unrelated dirty lockfile./just-vibe:deps Assess dependencies from the lockfile with unavailable advisory access.What the agent does
- Read manifests, resolved versions and peer/runtime ranges, and identify why each dependency exists.
- Check current release notes and advisories, and group changes by risk, isolating direct changes from lockfile churn.
- In apply mode, change the manifest through the project's package manager, then inspect the lockfile diff for unrelated churn before running checks.
Inputs
- package scope, update goal, compatibility constraints, and registry access when needed.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Dependency health and upgrade proposals; a requested update uses apply mode and includes lockfiles.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Inspect; package scope, update goal, compatibility constraints, and registry access when needed. Apply for a requested update through the project's package manager.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Current/target versions with compatibility risks and advisory evidence, and prioritized recommendations or, in apply mode, the requested update with its checks.
How the work is checked
- A peer conflict is detected; updating one package does not silently churn unrelated dependency versions.
When to stop or clarify
- Never treat latest as automatically best. Missing registry information is unknown, not proof of no vulnerabilities.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Inspect manifests, lockfiles, direct/transitive ownership, advisory evidence and supported versions.
- Method
- Separate security fixes from routine upgrades and assess API/engine/peer compatibility before changing the resolved graph.
- Pitfall
- Forced audit fixes or ignored peer conflicts can replace one issue with a runtime incompatibility.
- Check
- Inspect the resulting lockfile, run relevant behavior/build checks and retain unresolved advisories or inaccessible registry evidence.
Situational decisions
When an advisory has configuration-dependent exposure: Trace actual reachable use and report that condition before recommending a breaking upgrade.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.