Configuration Change Risk Prompt

This prompt is designed for DevOps, SRE, and platform engineering teams who need to review a diff of configuration files, environment variables, feature flags, or infrastructure-as-code templates before deployment. The core job-to-be-done is to identify misconfiguration risks, environment drift, and security exposure that could cause an outage, data leak, or compliance violation. It is not a general-purpose code review prompt; it is specifically tuned to reason about the operational blast radius of a configuration change, connecting a static diff to runtime behavior.

Use this prompt when you have a concrete diff of a configuration artifact—such as a Kubernetes ConfigMap, a Terraform variables file, a .env change, or a feature flag update—and you need a structured risk report before merging or applying the change. The ideal user is an engineer on a platform or reliability team who understands the system's architecture but wants an automated second pair of eyes to catch common failure patterns: missing dependencies, port conflicts, overly permissive security group rules, environment-specific value drift, or changes that disable health checks. The prompt requires the raw diff, the target environment (e.g., staging, production, us-east-1), and any relevant runtime context such as dependent services or known constraints.

Do not use this prompt for reviewing application source code, business logic, or algorithmic changes. It is not a substitute for a full security audit, a compliance review, or a load test. The output is a risk assessment, not a guarantee of safety. For high-risk production changes—especially those affecting authentication, encryption, network policy, or data storage—the prompt's findings must be reviewed and signed off by a human operator before the change is applied. If you lack the diff or the target environment context, stop and gather those inputs first; the prompt's accuracy degrades sharply without them.

This prompt template is designed to be copied directly into your AI harness, IDE, or CI/CD pipeline. It uses square-bracket placeholders for all dynamic inputs, allowing you to inject the specific configuration diff, environment context, and risk policies relevant to your review. The prompt instructs the model to act as a senior SRE, focusing on misconfiguration risks, environment drift, and security exposure.

codeCopy
You are a senior Site Reliability Engineer (SRE) reviewing a configuration change. Your task is to analyze the provided diff for risks related to misconfiguration, environment drift, and security exposure.

## Configuration Diff
```diff
[CONFIGURATION_DIFF]

Environment Context

• Target Environment: [TARGET_ENVIRONMENT] (e.g., production, staging, development)
• Service/Component: [SERVICE_NAME]
• Current Runtime Version: [CURRENT_VERSION]
• Relevant Runbook: [RUNBOOK_LINK]

Risk Policy

• Critical Risk Definition: [CRITICAL_RISK_DEFINITION] (e.g., Any change that could cause a full service outage, data loss, or a security breach)
• High Risk Definition: [HIGH_RISK_DEFINITION] (e.g., Performance degradation for >10% of users, exposure of non-sensitive internal data)
• Approval Required For: [APPROVAL_REQUIRED_FOR] (e.g., All critical and high-risk findings)

Output Schema

Produce a JSON object with the following structure. Do not include any text outside the JSON block. { "summary": "A one-sentence summary of the change.", "risk_level": "critical|high|medium|low", "findings": [ { "severity": "critical|high|medium|low", "category": "misconfiguration|environment_drift|security_exposure|other", "line_range": "The specific line numbers from the diff where the issue was found.", "description": "A clear, concise explanation of the risk.", "suggestion": "A concrete, actionable fix or mitigation.", "requires_approval": true|false } ], "drift_analysis": { "detected": true|false, "details": "Explanation of how the change deviates from the known baseline for [TARGET_ENVIRONMENT], or null if no drift is detected." } }

Constraints

• Base your analysis strictly on the provided diff and environment context.
• Do not invent information or assume external dependencies not visible in the diff.
• If the diff is empty or contains no meaningful changes, return a risk_level of 'low' with an empty findings array.
• Prioritize findings that match the provided risk policy definitions.

To adapt this template, replace the square-bracket placeholders with your specific data. The [CONFIGURATION_DIFF] should be the raw unified diff of the configuration files. The [TARGET_ENVIRONMENT] and [SERVICE_NAME] placeholders provide crucial context for drift analysis. The risk policy definitions are the most critical part to customize, as they calibrate the model's severity assessment to your organization's specific tolerance. The output schema is designed for direct ingestion by a downstream validation script or a review dashboard.

The Configuration Change Risk Prompt is designed to operate as a gating step in a deployment pipeline, not as a standalone chat interaction. The prompt expects a structured diff of configuration files, environment variable declarations, or feature flag definitions as its primary input. In a production harness, this diff should be extracted from a pull request or a release candidate comparison against the last known good state. The prompt's output—a structured risk report—should be parsed and used to make an automated decision: pass the change through, flag it for human review, or block the deployment entirely based on a predefined risk score threshold.

To integrate this into a CI/CD system, wrap the prompt call in a script that performs pre- and post-processing. Before calling the model, validate that the input diff is not empty and does not exceed the model's context window; if the diff is too large, split it by file and run the prompt in parallel, then merge the risk scores. After receiving the model's response, validate the JSON schema against a strict contract that requires fields like overall_risk_score (0-100), findings (an array of objects with file, line, risk, and rationale), and requires_human_review (boolean). If the JSON is malformed, use a repair prompt or a retry loop with exponential backoff. Log every prompt call, the raw diff, the model's response, and the validation result to an immutable audit store. For high-risk environments, configure the harness to automatically escalate any change where overall_risk_score exceeds 70 or requires_human_review is true, routing it to a dedicated Slack channel or ticketing system with the full risk report attached.

Model choice matters here. Use a model with strong JSON mode and a large context window, such as claude-sonnet-4-20250514 or gpt-4o, to reliably process multi-file configuration diffs. Avoid smaller or older models that may hallucinate line numbers or fail to adhere to the output schema. Implement a circuit breaker: if the model call fails three times or the output fails validation twice, fail the pipeline step safely by blocking the deployment and alerting the on-call engineer. Do not allow a failed AI review to silently pass a configuration change. The harness should treat an absent or invalid AI review as equivalent to a high-risk finding, defaulting to human approval for any change that could not be automatically assessed.