An Environment Config Review Prompt That Catches Drift Early

"Works in dev, breaks in prod" is almost never about the machine. It's about the config: a timeout that's 30 seconds in staging and 5 in production, a feature flag on in one place and off in another, an env var that exists in dev and silently doesn't in prod. An environment config review prompt finds those mismatches before they find you, by diffing two configs and telling you which differences are dangerous.

Environment configuration drift is when environments that should behave alike quietly diverge, through manual edits, ad-hoc fixes, and copy-paste config that aged differently. The bug ships through testing because staging didn't have the production setting that triggers it.

This is the job the Environment Parity Harness Pack runs end-to-end. The single prompt below is its core.

Why a raw diff isn't enough

OneUptime has a good environment parity guide with six steps and a validate-parity.sh script that compares database schemas. They also cover environment drift issues. Upsun writes about the repro gap and environment parity.

The advice is sound: containerize, use IaC, validate on a schedule. But the scripts and tooling stop at structural comparison. A schema diff tells you a column differs; it doesn't tell you that the differing connection-pool size is what's causing prod timeouts under load. And plenty of app config never lives in IaC at all. The gap is judgment: which of these forty differences actually matters? The prompt ranks them.

What you can do with this prompt

• Diff two environment configs and get differences grouped by type
• Rank each difference by severity, expected, suspicious, or likely bug
• Flag missing variables that exist in one environment and not the other
• Spot value mismatches that commonly cause production-only failures
• Get a parity plan: what to align, and guardrails to stop it drifting again
• Run the same review for dev-vs-staging or staging-vs-prod without rewriting it

Anatomy of the prompt

Variables
  {{env_a_config}}     – the first environment's config (e.g. staging)
  {{env_b_config}}     – the second environment's config (e.g. prod)
  {{expected_diffs}}   – differences that are intentional (hosts, scale)
  {{stack_notes}}      – what the service is sensitive to (timeouts, pools)

Prompt
  Role: platform engineer reviewing environment parity.
  Diff the configs. Classify each difference: expected, suspicious, or
  likely-bug. Ignore intentional diffs. Propose a parity plan + guardrails.

Output contract (locked)
  ## Drift findings (table: key, env A, env B, severity)
  ## Likely-bug differences (with reasoning)
  ## Parity plan
  ## Guardrails to prevent recurrence

The {{expected_diffs}} variable is what suppresses the noise. Tell the prompt that hostnames and replica counts are supposed to differ, and it stops flagging them, leaving the suspicious ones visible.

How to run it

1. Export both configs

Pull {{env_a_config}} and {{env_b_config}} in the same format, env files, rendered Helm values, whatever you've got. Matching formats make the diff cleaner.

2. Declare the intentional differences

{{expected_diffs}} is the noise filter. List the keys that are meant to differ. Skip this and you'll get a report that flags every hostname and trains you to ignore it.

3. Add stack sensitivity notes

{{stack_notes}} tells the prompt what your service actually cares about. If connection-pool size has bitten you before, say so, and the prompt will weight it.

4. Read the likely-bug findings first

The severity ranking is the point. Start with "likely-bug," confirm each one, then skim "suspicious." The "expected" bucket is just there to show its work.

5. Apply the parity plan and a guardrail

Fixing the drift once is half the job. The guardrails section is what stops it recurring, a CI check, a single source of truth, a locked-down prod.

Model behavior worth knowing

Claude is strong at the classification step: given {{stack_notes}}, it reasons about why a difference matters rather than just listing it, and it respects {{expected_diffs}} to suppress noise. GPT-4o produces tidy diff tables but tends to flag everything at medium severity unless you push it to commit to "likely-bug" vs "expected." Gemini handles large config blobs well but can truncate the findings table on very long inputs, so for big configs, split the review by section.

A reliable pattern here: put both configs first, the classification instructions and output contract last. On long pasted configs, a contract stated up front gets buried under the data and the model forgets the severity buckets. Models weight recent tokens, so the format spec belongs at the end of the prompt.

Variables you'll set

Getting started

1. Copy the prompt skeleton into ChatGPT, Claude, or Gemini.
2. Paste both configs into {{env_a_config}} and {{env_b_config}}.
3. List the intentional differences in {{expected_diffs}}.
4. Run it and read the likely-bug findings first.
5. Apply the parity plan to align the dangerous diffs.
6. Add one guardrail so the drift doesn't recur.
7. Reuse the prompt for the next environment pair.

Config drift is a sibling of infrastructure drift, so the Terraform drift detection prompt covers the IaC layer this prompt deliberately leaves alone. And when an environment-only failure does ship, the CI failure diagnosis prompt helps trace it back to the config difference that caused it.

Config that drifts often hides secrets that drift with it, so the Polyglot Secrets Management Playbook is the pack for the credential side of environment hygiene. Between parity and secrets, the gap between staging and prod stops being where bugs hide.