Dependency Version Conflict Resolution Prompt

This prompt is designed for developers and platform engineers who need to resolve package manager dependency conflicts automatically. It takes a raw dependency manifest file and the exact conflict error output from a tool like npm, pip, Maven, or Cargo, and proposes a compatible version set. Use this prompt inside a CI failure recovery step, a local developer CLI tool, or an automated dependency update bot.

The prompt works best when the conflict is purely a version resolution problem—where a set of compatible versions exists but the resolver cannot find it without explicit guidance. It requires two concrete inputs: the full dependency manifest (e.g., package.json, requirements.txt, pom.xml, or Cargo.toml) and the unmodified error text from the package manager. Without both, the model lacks the constraint surface needed to propose a working version set. The output should be a structured version override block that can be applied directly to the manifest or lock file, accompanied by a brief explanation of which constraints were relaxed or pinned to achieve resolution.

This prompt is not a replacement for a full dependency resolver or a human architect when the conflict stems from a fundamental API incompatibility that requires code changes. If a package has removed a function your code calls, no version pinning will fix it. Similarly, do not use this prompt for security vulnerability triage—it does not assess CVE risk, only compatibility. For high-risk production deployments, always pair the prompt's output with a lock file regeneration test and a human review step before merging.

This template is designed to be pasted directly into your AI harness. It accepts a dependency manifest, a package manager error log, and optional constraints to produce a resolved version set. The prompt instructs the model to reason about transitive dependencies, explain its resolution strategy, and output a machine-readable lock file diff. All placeholders are enclosed in square brackets and must be replaced with concrete values before execution.

textCopy
You are a dependency resolution engineer. Your task is to resolve a version conflict reported by a package manager.

## INPUT
- Package manager: [PACKAGE_MANAGER]
- Dependency manifest file content:
  ```[MANIFEST_FORMAT]
  [MANIFEST_CONTENT]

• Error output from the package manager:

  codeCopy
  [ERROR_LOG]

CONSTRAINTS

• [CONSTRAINTS]

OUTPUT_SCHEMA

Return a JSON object with the following structure: { "resolution_strategy": "string explaining the approach taken", "conflict_analysis": { "root_cause": "string identifying the primary conflict", "affected_packages": ["package@version", ...], "constraint_paths": ["dependency -> parent -> root", ...] }, "resolved_versions": { "[PACKAGE_NAME]": "[RESOLVED_VERSION]", ... }, "lock_file_diff": "string showing the minimal changes to the lock file", "transitive_consistency_check": { "passed": true, "notes": "string explaining why the set is consistent" }, "regeneration_command": "string with the exact command to regenerate the lock file" }

INSTRUCTIONS

1. Parse the error log to identify the exact conflicting packages and their version constraints.
2. Trace the dependency graph to find all constraint paths leading to the conflict.
3. Propose a compatible version set that satisfies all direct and transitive constraints.
4. If no compatible set exists, explain the unresolvable conflict and suggest the minimal set of constraint relaxations required.
5. Ensure the resolved versions are consistent across all transitive dependencies.
6. Output only the JSON object. Do not include any other text.

To adapt this template, replace each placeholder with concrete values. [PACKAGE_MANAGER] should be one of npm, pip, maven, or cargo. [MANIFEST_FORMAT] should be the file type such as json, yaml, toml, or xml. [CONSTRAINTS] can include directives like "Do not upgrade major versions" or "Prefer the latest patch within the current minor range." For high-risk production environments, add a [RISK_LEVEL] field and require a human review step before applying the lock file diff. Always validate the regenerated lock file in a CI sandbox before merging.

This prompt is designed to be called programmatically from a build pipeline, pre-commit hook, or developer CLI. The harness should capture the raw package manager error output (stdout/stderr) and the full dependency manifest file as the two primary inputs. For npm, this means package.json plus the conflict error from npm install. For pip, requirements.txt or pyproject.toml plus the pip install resolution failure. For Maven, pom.xml plus the dependency tree conflict. For Cargo, Cargo.toml plus the resolver error. The harness must not truncate error output—transitive dependency conflicts often appear deep in the error trace, and cutting it short will cause the model to miss the root cause.

After the model returns a proposed version set, the harness must validate the output before applying it. Parse the response for a structured version map (e.g., {"package": "version"}) and run a dry-run install using the package manager's native resolver. For npm, execute npm install --dry-run after applying the suggested versions to package.json. For pip, use pip install --dry-run with the proposed pinned versions. If the dry-run fails, feed the new error back into the prompt as a retry with the previous suggestion included as context. Implement a retry budget of 3 attempts before escalating to a human. Log each attempt's input, output, and dry-run result for auditability. The harness should also regenerate the lock file (package-lock.json, Pipfile.lock, pom.xml with resolved versions, Cargo.lock) only after a successful dry-run, and commit the change with a message that cites the original conflict error.

For high-risk environments (production deployments, monorepos with shared dependencies, regulated build pipelines), require human approval before applying the suggested version changes. The harness should surface a diff of the dependency manifest changes alongside the model's explanation and the dry-run result. Do not auto-merge version conflict resolutions that change major versions or remove pinned transitive dependencies without review. Avoid wiring this prompt into fully automated CD pipelines without a manual gate—version resolution errors can introduce subtle runtime incompatibilities that pass a dry-run but fail integration tests. Pair this prompt with a subsequent test suite run as a required validation step before the change is accepted.