Dependency Pinning Strategy Evaluation Prompt

This prompt is designed for build engineers, platform teams, and technical leads who need to decide between version ranges, exact pins, and lockfile-only strategies across multiple package ecosystems. The job-to-be-done is producing a concrete, defensible recommendation per dependency category—not a generic best practice list. Use it when your team is standardizing dependency management policy, evaluating a new package manager, or reconciling conflicting pinning approaches across services. The prompt assumes you have already identified the ecosystems in play (e.g., npm, pip, cargo, Maven) and can articulate your team's priorities around reproducibility, security patch velocity, and maintenance overhead.

Do not use this prompt when you are debugging a single broken build, triaging one dependency update PR, or diagnosing a specific version conflict. Those tasks require narrower prompts focused on root-cause analysis or risk scoring for individual packages. This prompt is also inappropriate when the team has no stated priorities or risk tolerance—without explicit trade-off preferences, the model will produce generic advice that fails under real operational pressure. If your dependency graph is not yet mapped, run a dependency graph impact analysis prompt first so the pinning strategy evaluation has concrete categories to reason about.

Before invoking this prompt, gather the following context: the list of package ecosystems in use, the team's ranked priorities (e.g., reproducibility over patch speed), any compliance or security policies that constrain version selection, and examples of dependency categories you want evaluated (e.g., frameworks, CLI tools, transitive-only libraries, build plugins). The prompt produces a decision matrix mapping each category to a recommended strategy with rationale, migration steps, and a risk register. After receiving the output, validate that every recommendation is consistent with your stated priorities and that migration steps reference real toolchain commands, not hallucinated flags. For high-risk production environments, run the output through a peer review step before committing it to team policy documentation.

This prompt template is designed to produce a structured evaluation of dependency pinning strategies—version ranges, exact pins, and lockfile-only approaches—across the ecosystems your team uses. It forces the model to reason about reproducibility, security patch velocity, and maintenance overhead per dependency category before making a recommendation. The template is copy-ready: replace each square-bracket placeholder with your team's actual context, priorities, and constraints. The output includes a decision matrix and migration steps, making it suitable for direct use in a CI/CD review pipeline or an architecture decision record.

textCopy
You are a build and dependency management specialist evaluating pinning strategies for a software team.

## TEAM CONTEXT
- Ecosystem(s): [ECOSYSTEMS, e.g., npm, pip, cargo, maven]
- Repository type: [REPO_TYPE, e.g., monorepo, polyrepo, monolith]
- Deployment model: [DEPLOYMENT_MODEL, e.g., containerized, serverless, on-prem]
- Team size and structure: [TEAM_SIZE_AND_STRUCTURE]
- Current pinning approach: [CURRENT_APPROACH]
- Pain points with current approach: [PAIN_POINTS]

## PRIORITIES
Rank these priorities from 1 (highest) to 5 (lowest):
- Reproducibility: [REPRODUCIBILITY_RANK]
- Security patch velocity: [SECURITY_PATCH_RANK]
- Maintenance overhead: [MAINTENANCE_RANK]
- Build determinism: [BUILD_DETERMINISM_RANK]
- Developer experience: [DEVEX_RANK]

## DEPENDENCY CATEGORIES
For each category below, provide the approximate count and risk tolerance:
- [CATEGORY_1_NAME]: [COUNT] packages, risk tolerance [LOW/MEDIUM/HIGH]
- [CATEGORY_2_NAME]: [COUNT] packages, risk tolerance [LOW/MEDIUM/HIGH]
- [CATEGORY_3_NAME]: [COUNT] packages, risk tolerance [LOW/MEDIUM/HIGH]
(Add or remove categories as needed)

## CONSTRAINTS
- [CONSTRAINT_1, e.g., Must pass SOC2 audit requirements]
- [CONSTRAINT_2, e.g., CI pipeline must complete in under 10 minutes]
- [CONSTRAINT_3, e.g., Cannot introduce new tooling this quarter]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "strategy_per_category": [
    {
      "category": "string",
      "recommended_strategy": "exact_pin | version_range | lockfile_only",
      "rationale": "string explaining trade-off for this category given priorities",
      "reproducibility_score": "high | medium | low",
      "security_patch_velocity_score": "high | medium | low",
      "maintenance_overhead_score": "high | medium | low",
      "implementation_effort": "low | medium | high",
      "specific_config_example": "string showing the lockfile or manifest syntax"
    }
  ],
  "decision_matrix": {
    "rows": ["exact_pin", "version_range", "lockfile_only"],
    "columns": ["reproducibility", "security_patch_velocity", "maintenance_overhead", "build_determinism", "developer_experience"],
    "scores": [["high|medium|low", ...], ...]
  },
  "cross_ecosystem_consistency_notes": "string describing whether the same strategy works across all ecosystems or if divergence is warranted",
  "migration_steps": [
    {
      "phase": "number",
      "action": "string",
      "verification": "string describing how to confirm the step succeeded",
      "rollback": "string describing how to undo if verification fails"
    }
  ],
  "risks_and_mitigations": [
    {
      "risk": "string",
      "severity": "high | medium | low",
      "mitigation": "string"
    }
  ],
  "recommended_tooling": ["string"],
  "confidence": "high | medium | low",
  "uncertainty_notes": "string describing what information would increase confidence"
}

## INSTRUCTIONS
1. Evaluate each dependency category independently against the stated priorities.
2. Do not recommend a strategy that contradicts a hard constraint.
3. If two strategies are close, explain the tiebreaker in the rationale.
4. For migration steps, include verification and rollback for every phase.
5. If confidence is medium or low, explain exactly what additional information would raise it.
6. Do not invent package names, version numbers, or tool features you are unsure about.

To adapt this template, start by filling in the team context and priorities honestly—the quality of the output depends on accurate inputs. If you have more than three dependency categories, add them; if you have fewer, remove the extras. The output schema is strict JSON, so you can pipe the result directly into a decision document or a CI check that validates the schema before merging. For high-risk production environments, add a human review step after the model returns its recommendation: have a senior engineer verify that the migration steps reference real file paths and that the recommended tooling is actually available in your environment. If the model returns medium or low confidence, treat the output as a starting point for discussion rather than a final decision.

This prompt is designed to be called programmatically as part of a dependency review workflow, not as a one-off chat interaction. The primary integration point is a CI/CD pipeline step or an internal developer portal where a team triggers a pinning strategy evaluation for a specific [ECOSYSTEM] and [MANIFEST_PATH]. The application layer should gather the required inputs—the dependency manifest, the lockfile, the team's stated priorities, and any known constraints—and assemble them into the [INPUT] and [CONTEXT] blocks before calling the model. Because the output is a structured decision matrix with migration steps, the harness must parse the model's response into a typed object (e.g., a JSON schema with fields for recommendation_per_category, decision_matrix, and migration_steps) and validate it before surfacing it to the user or writing it to a review artifact.

Validation and retry logic is critical here. The harness should validate that every dependency category in the input manifest appears in the output, that each recommendation includes the required rationale fields (reproducibility, security patch velocity, maintenance overhead), and that the decision matrix is internally consistent with the team's stated priorities. If validation fails, the harness should retry with the same inputs and an additional [CONSTRAINTS] note describing the specific validation error (e.g., 'The previous output omitted the dev-dependencies category; include it in the decision matrix'). Set a maximum of two retries before escalating to a human reviewer. For high-risk repositories (e.g., production services, security-critical libraries), always require a human approval step before any migration steps are executed. The approval gate should display the parsed recommendation, the decision matrix, and a diff of proposed pinning changes against the current manifest.

Model choice and tool use depend on the complexity of the dependency graph. For small to medium manifests (under 100 direct dependencies), a capable instruction-following model with a 128K+ context window is sufficient, and the prompt can operate purely on the provided manifest and lockfile text. For large monorepos or ecosystems with deep transitive trees, consider adding a retrieval step: use a dependency graph tool (e.g., npm ls --json, pipdeptree, or a custom graph resolver) to pre-compute the transitive impact of each pinning strategy and inject that as structured [CONTEXT] before calling the model. This reduces hallucination risk when the model reasons about downstream effects. Log every evaluation run—inputs, raw output, validation result, retries, and final recommendation—to an audit table so teams can trace why a particular pinning strategy was recommended six months later. Do not use this prompt to auto-apply changes without human review in any repository where a broken build would block other teams or affect production deployments.