Vulnetix Dependency Resolution Skill

Use when

• fix proposed a version bump but <pm> install errored on peer-dep conflict.
• A transitive vulnerable dep needs pinning without bumping the direct dependency.
• Lockfile resolution fails after a merge — diagnose which deps disagree.
• Considering a package-manager override (npm overrides, pnpm overrides, yarn resolutions).
• Last-resort: copy patched upstream code inline as first-party (Type A0 inline).

Don't use for

• Initial fix proposal — use fix first.
• Just looking up safe versions — use dependency-choice.
• Multi-CVE upgrade orchestration — use @dep-upgrade-orchestrator.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

When fix proposes a version bump but the lockfile resolution fails (peer-dep conflict, transitive constraint, etc.), use this skill to find a compatible set.

Step 1: Load capabilities + memory

Read .vulnetix/capabilities.yaml (derived.primary_package_manager decides which lockfile to read) and .vulnetix/memory.yaml (decisions / safe-harbour notes).

Step 2: Map the conflict

# npm/pnpm/yarn
npm ls "$PACKAGE" 2>&1 || pnpm why "$PACKAGE" || yarn why "$PACKAGE"
# pip
pip show "$PACKAGE"
# go
go mod why "$PACKAGE"
# cargo
cargo tree -i "$PACKAGE"

Pick the command for the detected package manager. Capture the dep tree paths.

Step 3: Pull safe-version graph

vulnetix vdb versions "$PACKAGE" -o json
vulnetix vdb fixes "$PACKAGE" -o json

For each candidate target version:

• Cross-check transitive constraints from Step 2
• Cross-check known vulns at that version (vdb vulns)

Step 4: Propose resolution

Prefer (in order):

1. Single bump — newest patch version that fixes the vuln and satisfies constraints
2. Override — package-manager override (npm overrides, pnpm pnpm.overrides, yarn resolutions)
3. Safe-harbour inline — copy upstream patch into repo as first-party code (link to fix Type A0 path)
4. Workaround only — detection-rules <vuln-id> while waiting for upstream

Step 5: Apply (with confirmation)

For option 1: edit the manifest, run <pm> install (npm/pnpm/yarn/pip/go/cargo). For option 2: write the override block, run install. For option 3: hand off to fix Type A0. For option 4: hand off to detection-rules.

Always pause for user approval before writing manifest edits.

Step 6: Verify

Suggest verify-fix <vuln-id> after the resolution lands.

Memory update

event: dep-resolve with the chosen path.

Edge cases & gotchas

• Dep-tree diagnosis uses package-manager-specific commands: npm ls, pnpm why, yarn why, pip show, go mod why, cargo tree -i. Wrong PM = misleading output.
• Override semantics differ per ecosystem: npm overrides is post-install hoist, pnpm pnpm.overrides is install-time pinning, yarn resolutions works with both classic and Berry but with different scoping.
• Pip has no clean override — pinning the transitive in requirements.txt + --no-deps for the parent is the cleanest workaround.
• Go replace directives work only when the module path is identical (no rename through fork).
• Cargo [patch] requires the patched crate at a real path or git ref; cannot inline a hex string.
• Inline-as-first-party (Type A0) introduces license obligations from the upstream package — copy the LICENSE file too.