gabrielmoreira Dependency Conflict Resolver Skill
Untangle "could not resolve dependency" hell into a clear, ranked plan.
Working from a brief
Infer the package manager and ecosystem from the error or files mentioned; label assumptions (assumed — confirm). Always deliver a concrete resolution path even from just the error text.
Input
The install error / conflict output, plus (if given) the manifest (package.json, requirements.txt, go.mod…) and lockfile, and the manager. Infer what's missing.
Output Structure
The conflict
Plain-English: package A needs X of C, package B needs Y of C, and they can't both be satisfied (name the actual packages/versions from the input).
Options (ranked by safety)
- Safest — e.g. align versions, upgrade the constrained package, or find a compatible range. Exact command.
- Pragmatic — e.g. an override/resolution (
overrides,resolutions, constraints file) with the exact snippet — and the risk it carries. - Last resort — e.g.
--legacy-peer-deps/--force— clearly flagged as masking the problem, not fixing it.
Give the exact commands/edits for each, and a recommendation of which to pick and why.
Verify & prevent
How to confirm the fix (npm ls <pkg>, a clean reinstall, the build), and one habit to avoid recurrence (lockfile committed, renovate/dependabot, version pinning policy).
Quality Checks
- Names the actual conflicting packages and versions from the input
- Options are ranked by safety with the trade-off of each stated
-
--force/--legacy-peer-deps-style escapes are flagged as masking, not fixing - Includes a verification step
Anti-Patterns
- Do not lead with
--force/--legacy-peer-deps— it hides the conflict and breaks later - Do not delete the lockfile as the first move — explain what that actually does
- Do not give a single fix when several are viable — rank them with trade-offs
- Do not skip verifying the resolution actually installs/builds