agentleFS
CaduS0uzaCaduS0uza/qa-supreme/skills/environment-parity/SKILL.md

environment-parity

Skill1 starsChanged 2 months agoMITView on GitHub

Prove that staging actually predicts production — same config keys, same migrations, same feature flags, same integrations — and catch the differences that make a green staging run meaningless. Use before trusting a staging result, after a deploy that behaved differently than expected, or when something worked in staging and broke in production.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run it before you trust any staging result, and again after any environment change:

    line 16
  2. Distinctive:

    Never let a test environment reach a production integration: Not the payment provider, not the mail sender, not the webhook target, not the …

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Environment Parity

"It worked in staging" is the most expensive sentence in software. It is usually true, and it is usually irrelevant, because staging differed from production in exactly the way that mattered.

The failure is almost never the code. It is a missing environment variable, a migration that ran in one place, a flag on in one place, an integration pointing somewhere else.

The parity check

Run it before you trust any staging result, and again after any environment change:

DimensionProve it byTypical divergence
Config keyslist keys (never values) in both, diff the setsa token that exists only in prod, so the feature is untested
Config shapesame key, different kind of valuea sandbox URL in staging and a live one in prod
Migrationscompare applied migration listsstaging is ahead, so the schema you tested is not the one you ship to
Feature flagsdump flag state per environmentflag on in staging, off in prod: you tested code nobody will run
Integrationsresolve each third party's targetstaging pointing at a production webhook — the dangerous one
Data shaperow counts and cardinality of key tables50 rows in staging, 5M in prod: every query plan differs
Runtimelanguage, framework, region, memory, timezoneUTC in staging, local in prod
Buildthe served commit shayou tested a build that was never deployed
# keys only — never print values
diff <(vercel env ls preview | awk '{print $1}' | sort) \
     <(vercel env ls production | awk '{print $1}' | sort)

The three rules

  1. Assert the served build. Expose the commit sha on a health endpoint and assert it matches what you deployed. Half of "the fix didn't work" is "the fix was never deployed".
  2. A key that exists in only one environment is a finding, even when nothing is failing yet. It means one of the two environments is not testing that path at all.
  3. Never let a test environment reach a production integration. Not the payment provider, not the mail sender, not the webhook target, not the customer's database. Assert the target hosts at startup and refuse to boot on a mismatch — that check is cheaper than the incident.

Where parity is allowed to break

Perfect parity is not the goal; known divergence is. Write the exceptions down and justify each one: smaller instance sizes, sandbox payment keys, anonymised data volume, a shorter retention window. Anything not on that list is a defect.

Any behaviour that only exists where parity is broken — a webhook that only production can receive, a provider that has no sandbox — cannot be validated before release. Say that out loud in the release-gate rather than letting a green staging run imply coverage it does not have, and plan the post-deploy check that will actually verify it (smoke-and-sanity).

After the deploy

Parity is not a one-time audit. Re-run the check after every environment change, and run a production sanity pass within 60 seconds of every promotion — then again five minutes later, because caches and CDNs lie for a while.

Done means

A diff of config keys, migration lists and flag state between environments; the served sha asserted; the exception list written down; and any behaviour that staging structurally cannot prove named explicitly.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.