Infrastructure Module Version Bump Risk Prompt

This prompt is designed for platform engineering and SRE teams responsible for maintaining infrastructure-as-code (IaC) modules, specifically Terraform or Pulumi packages. The core job-to-be-done is to evaluate the risk of upgrading a module version by analyzing its changelog or release notes. The ideal user is a senior engineer or tech lead who needs a structured, evidence-backed go/no-go recommendation before opening a pull request, not a developer looking for a generic summary of new features. The prompt requires a specific changelog diff and the current module version as inputs; without these, the analysis will be speculative and unreliable.

Use this prompt when a module version bump could introduce breaking changes, deprecate inputs, require state migrations, or conflict with provider version constraints. It is particularly valuable for shared modules consumed by multiple service teams, where a single upgrade can have a wide blast radius. The prompt is not a replacement for reading the changelog yourself or running terraform plan; it is a pre-implementation risk assessment tool. Do not use this prompt for trivial patch bumps with no functional changes, for modules outside your organization's governance scope, or when the changelog is empty or unavailable. In those cases, the prompt will either produce low-value output or hallucinate risks from insufficient evidence.

The output is a structured risk report, not a simple yes/no. It must include a clear go/no-go recommendation, a categorized list of breaking changes and deprecations, an assessment of state migration complexity, and a rollback difficulty rating. Before relying on the recommendation, you must validate the prompt's output against the actual module source code and your own environment's state. For high-risk modules controlling critical infrastructure (e.g., networking, databases, or authentication), always require a human reviewer to sign off on the recommendation before any apply is executed. The next step after reading this section is to gather the required inputs: the full changelog text between your current and target versions, your current module version, and any known provider version constraints.

This prompt template is designed to be copied directly into your AI harness, whether you're using a chat interface, API call, or automated CI/CD pipeline integration. It expects structured inputs including the module changelog, current and target versions, and your existing configuration context. The square-bracket placeholders indicate where you should inject real data before execution. Replace each placeholder with actual values from your infrastructure-as-code repository and module registry.

codeCopy
You are an infrastructure reliability engineer reviewing a Terraform module version upgrade. Your task is to analyze the changelog diff between the current version and the target version, assess breaking changes, state migration requirements, provider constraints, and produce a structured go/no-go recommendation with rollback complexity assessment.

## INPUTS

**Module Name:** [MODULE_NAME]
**Module Source:** [MODULE_SOURCE_URL]
**Current Version:** [CURRENT_VERSION]
**Target Version:** [TARGET_VERSION]
**Changelog Diff:**
[CHANGELOG_DIFF]

**Current Module Configuration:**
```hcl
[CURRENT_MODULE_CONFIG]

Provider Version Constraints: [PROVIDER_CONSTRAINTS]

Deployment Environment: [ENVIRONMENT_NAME] Affected Resources Count: [AFFECTED_RESOURCES_COUNT]

OUTPUT SCHEMA

Return a JSON object with this exact structure: { "recommendation": "GO" | "NO_GO" | "CONDITIONAL_GO", "risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL", "breaking_changes": [ { "change_description": "string", "affected_inputs": ["string"], "migration_required": true | false, "migration_steps": ["string"] | null, "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL" } ], "deprecated_inputs": [ { "input_name": "string", "replacement": "string" | null, "removal_version": "string" | null } ], "state_migration_required": true | false, "state_migration_details": "string" | null, "provider_constraint_conflicts": [ { "provider": "string", "required_version": "string", "current_constraint": "string", "resolution": "string" } ], "rollback_complexity": "SIMPLE" | "MODERATE" | "COMPLEX" | "DESTRUCTIVE", "rollback_notes": "string", "testing_recommendations": ["string"], "confidence": 0.0-1.0, "evidence_links": ["string"] }

CONSTRAINTS

• Only flag breaking changes that are confirmed in the changelog diff. Do not speculate about unlisted changes.
• If the changelog explicitly states state migration is required, set state_migration_required to true and provide exact steps from the changelog.
• For CONDITIONAL_GO recommendations, specify exactly which conditions must be met before proceeding.
• Assign CRITICAL risk only when the upgrade includes destructive changes, irreversible state modifications, or documented data loss scenarios.
• If provider version constraints conflict, list each conflict with a specific resolution path.
• Rollback complexity DESTRUCTIVE means rollback is not possible without data loss or manual state recovery.
• Confidence must reflect how complete and clear the changelog diff is. Lower confidence when changelog entries are vague or missing detail.
• Base all findings on the provided changelog diff. Do not pull external information unless explicitly instructed.

EVALUATION STEPS

1. Parse the changelog diff for explicit breaking change notices, deprecation warnings, and upgrade notes.
2. Compare deprecated inputs against the current module configuration to identify affected blocks.
3. Check target version provider requirements against current provider constraints.
4. Assess whether state migration is documented and whether it is automatic or manual.
5. Evaluate rollback feasibility: can the previous version be reapplied without state corruption?
6. Assign risk level based on the highest-severity finding, not the average.
7. Generate testing recommendations specific to the affected resources and changed inputs.

To adapt this template for your environment, replace the [CURRENT_MODULE_CONFIG] placeholder with the actual HCL block from your Terraform configuration that calls this module. The [CHANGELOG_DIFF] should contain the full diff between your current version and the target version, typically sourced from the module registry's changelog or a git diff between release tags. If your organization uses Pulumi instead of Terraform, replace the HCL configuration block with your Pulumi code in the appropriate language and adjust the output schema's deprecated_inputs field to reference Pulumi input properties. For CI/CD integration, wire the [AFFECTED_RESOURCES_COUNT] from your plan output to give the model context about blast radius. Always validate the JSON output against the schema before surfacing the recommendation to a human reviewer, especially for HIGH or CRITICAL risk assessments where a false GO could cause an outage.

This prompt is designed to operate as a gating step in an automated infrastructure change pipeline, not as a standalone chat interaction. The primary integration point is a pull request or merge request webhook that triggers when a developer updates a Terraform or Pulumi module version constraint in a versions.tf, main.tf, or similar manifest. The application harness must extract the changelog for the specific module version delta, feed it into the prompt alongside the current and proposed version constraints, and parse the structured go/no-go recommendation from the model's response. Because the output directly influences whether a version bump proceeds to plan/apply stages, the harness must enforce a human approval gate for any recommendation that is not a clear 'go' with low rollback complexity.

The implementation should follow a strict pre-processing, inference, and post-processing sequence. First, the harness must resolve the module source to its registry or repository, fetch the changelog between the current and target versions, and extract the provider version constraints from both the module's documentation and the project's required_providers block. These become the [CHANGELOG_DIFF], [CURRENT_VERSION], [TARGET_VERSION], and [PROVIDER_CONSTRAINTS] inputs. After inference, the harness must validate the JSON output against a strict schema that requires the recommendation field to be one of go, no-go, or conditional-go, and the rollback_complexity field to be one of low, medium, or high. Any response that fails schema validation should trigger a single retry with the validation error appended to the prompt as additional [CONSTRAINTS]. If the retry also fails, the harness must fail closed by blocking the version bump and alerting the platform team.

For model selection, use a model with strong structured output capabilities and a context window large enough to hold the full changelog diff. Enable JSON mode or structured output features if available. Log the full prompt, raw response, parsed recommendation, and any validation errors to your observability platform for auditability. The most common production failure mode is an incomplete or unparseable changelog from the module registry, which causes the model to hallucinate breaking changes or miss deprecations. Mitigate this by implementing a pre-flight check that verifies the changelog fetch succeeded and contains version-specific entries before invoking the model. If the changelog is unavailable, the harness should route to a manual review queue rather than attempting inference with degraded inputs.