Helm Chart Values Override Review Prompt

This prompt is designed for platform teams, SREs, and DevOps engineers who manage Helm charts across multiple environments. The core job-to-be-done is catching configuration regressions before they ship: a developer opens a PR that modifies a values-production.yaml override, and you need a structured, evidence-backed review that compares the diff against the chart's default values.yaml to detect environment parity breaks, missing required values, and resource limit regressions. The ideal user has access to both the proposed diff and the chart's defaults, and needs a review that is faster and more consistent than a manual line-by-line comparison, but still requires human sign-off for critical changes.

Use this prompt in automated PR checks, pre-deployment review gates, or GitOps change pipelines (e.g., ArgoCD or Flux pre-sync hooks) where configuration changes need a structured risk assessment before reaching a cluster. It is particularly effective when your team manages multiple environments with inheritance or overlay patterns, and you want to enforce rules like 'staging and production must have identical resource limits' or 'every environment must explicitly set liveness probe values.' The prompt works best when you provide the full default values.yaml as [CHART_DEFAULTS] and the proposed override file as [PROPOSED_OVERRIDES], along with a clear [ENVIRONMENT] label and any team-specific [CONSTRAINTS] such as required fields or parity rules.

Do not use this prompt as a substitute for Helm's built-in schema validation, helm lint, or kubeconform. It will not catch YAML syntax errors, API version mismatches, or Kubernetes schema violations—those belong in your CI pipeline before this review step. It is also not a security scanner; while it can flag obvious issues like privileged: true or hostPath mounts, it will not perform deep container escape analysis or CVE checks. For high-risk production changes, always require a human reviewer to approve the prompt's findings before merge. The prompt's output should be treated as a structured review aid, not an automated approval.

After reading this section, you should have a clear picture of where this prompt fits in your pipeline. Next, copy the prompt template, adapt the placeholders to your chart and environment structure, and wire it into a PR check that blocks merges only on critical findings while allowing informational warnings to pass through.

The prompt below is designed to be dropped into your AI review harness—whether that's a CI/CD pipeline step, a PR bot, or a manual review tool. It expects two inputs: the environment-specific values file diff and the chart's default values.yaml as a baseline. Replace every square-bracket placeholder with real data before execution. The prompt instructs the model to produce a structured JSON report, not freeform commentary, so you can parse the output directly in your pipeline.

textCopy
You are a platform engineering reviewer. Analyze the Helm chart values override diff against the default values.yaml.

## INPUTS
- ENVIRONMENT: [ENVIRONMENT_NAME]
- CHART: [CHART_NAME]
- DEFAULT VALUES: [DEFAULT_VALUES_YAML]
- OVERRIDE DIFF: [OVERRIDE_DIFF]

## OUTPUT_SCHEMA
Return valid JSON matching this schema:
{
  "environment": "string",
  "chart": "string",
  "findings": [
    {
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "category": "RESOURCE_LIMIT | ENVIRONMENT_PARITY | MISSING_REQUIRED | SECURITY | DRIFT | OTHER",
      "path": "dot.separated.yaml.path",
      "summary": "one-line description",
      "default_value": "value from default values.yaml or null",
      "override_value": "value from override diff or null",
      "rationale": "why this matters in production",
      "recommendation": "specific fix action"
    }
  ],
  "parity_score": 0.0-1.0,
  "requires_human_approval": true/false
}

## CONSTRAINTS
1. Compare every override key against the default values.yaml. Flag any override that removes or substantially alters a default without clear environment justification.
2. Flag missing required values that have no default and no override.
3. For resource limits, flag any decrease in CPU/memory requests or limits that could cause OOMKilled or CPU throttling regressions.
4. Flag environment-specific values that break parity with production (e.g., replica counts, feature flags, ingress rules) and assess blast radius.
5. If any finding is CRITICAL, set requires_human_approval to true.
6. Do not flag values that are intentionally environment-specific and documented as such in the diff comments.
7. If the override diff is empty or only contains comments, return an empty findings array and a parity_score of 1.0.

## RISK_LEVEL: HIGH
This review gates production deployments. False negatives can cause outages. When uncertain, escalate severity.

Adaptation notes: Replace [ENVIRONMENT_NAME] with the target environment (e.g., production, staging, dev-us-east). [CHART_NAME] should be the chart's fully qualified name. [DEFAULT_VALUES_YAML] is the raw content of the chart's default values.yaml—do not summarize it. [OVERRIDE_DIFF] is the unified diff or full content of the environment-specific override file. If your pipeline can only pass diffs, ensure the diff includes enough context lines for the model to understand the surrounding YAML structure. For high-throughput pipelines, consider caching the default values and only sending the diff to reduce token usage.

Before integrating this prompt into an automated merge gate, run it against a golden dataset of known-good and known-bad overrides. Measure precision on CRITICAL findings (you want near-zero false positives) and recall on resource limit regressions (you want near-zero false negatives). If the model flags intentional environment differences as CRITICAL, add clarifying comments to your override files or adjust the constraint wording in the prompt. Always require human approval for CRITICAL findings in production-bound changes—this prompt is a review accelerator, not a replacement for platform engineering judgment.

This prompt is designed to operate as a gated step in a GitOps or CI/CD workflow, triggered by pull requests that modify Helm values files. The primary integration point is a webhook or CI job that detects changes to values-*.yaml files, extracts the diff, and sends it to the model along with the default values.yaml for comparison. The harness must enforce a strict contract: the model receives a structured input payload containing the environment values diff, the base default values, and the target environment name, and it must return a valid JSON object matching the expected risk report schema before the pipeline can proceed.

Validation and Retry Logic: The harness must validate the model's JSON output against a predefined schema that enforces required fields (finding_id, severity, category, description, affected_key, recommendation). If validation fails, implement a single retry with the validation error message injected into the prompt as additional [CONSTRAINTS] context. If the retry also fails, the pipeline must fail open with a clear log message indicating a model output error, preventing a silent pass. For high-risk environments, add a human approval gate that blocks merge if any finding has a severity of critical or high, posting the structured findings directly into the PR as a review comment for manual acknowledgment.

Model Choice and Tool Use: For this task, a model with strong JSON mode and structured output support (such as gpt-4o or claude-3.5-sonnet) is recommended. Do not use tool calling for the output itself; rely on the model's native structured output or JSON mode to enforce the schema. However, you can wire a pre-processing tool that fetches the default values.yaml from the chart repository if it is not included in the PR diff, ensuring the model always has a baseline for drift analysis. Log every request and response payload, including the validated output and any retry attempts, to an observability platform for auditability and prompt debugging.

What to Avoid: Do not wire this prompt directly into an automated merge or apply action without human review for critical findings. Avoid running the prompt on every commit; trigger it only on PR creation or update when values files change. Do not skip schema validation, as malformed JSON will break downstream PR comment automation. Finally, ensure the harness handles the case where no diff exists (e.g., a PR that touches only non-values files) by skipping the check entirely rather than sending an empty diff to the model.