audit-env-parity
Skill9 starsChanged 43 days agoMITView on GitHub
Read-only audit of config parity across dev, staging, and prod: missing or misnamed vars, drifted flags, hardcoded values, reused secrets. Use when "works locally but not in prod", "audit our environments", or "config drift".
- Reads credentials
1 other project uses a version of this.
Adopted by
Most recently taken up by
- kensaurus/skillsword for word, first seen Oct 1, 2026
Other versions1 project uses a version of this.
Word for word · 1
- kensaurus/skills★ 9100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository165 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/approved-plan-execution.mdcCursor rule
- .cursor/rules/skill-workflows.mdcCursor rule
- .cursor/rules/verification-before-completion.mdcCursor rule
- llms.txtllms.txt
- audit-accessibilitySkill
- audit-agent-speedSkill
- audit-analyticsSkill
- audit-auth-flowsSkill
- audit-backend-architectureSkill
- audit-bundle-sizeSkill
- audit-cicdSkill
- audit-codemod-safetySkill
- audit-code-qualitySkill
- audit-code-reviewSkill
- audit-db-schemaSkill
- audit-doctrineSkill
- audit-fe-apiSkill
- audit-gate-logicSkill
- audit-i18nSkill
- audit-infra-costSkill
- audit-langfuse-llmSkill
- audit-llm-securitySkill
- audit-monetization-iapSkill
- audit-payment-systemSkill
- audit-performanceSkill
- audit-realworldSkill
- audit-registry-listingSkill
- audit-resilienceSkill
- audit-responsiveSkill
- audit-securitySkill
- audit-skill-conflictsSkill
- audit-ui-statesSkill
- audit-uiux-design-systemSkill
- audit-ux-journeysSkill
- audit-uxSkill
- backend-db-performanceSkill
- backend-error-handlingSkill
- backend-observabilitySkill
- backend-patternsSkill
- backend-realtimeSkill
- burndown-fullSkill
- complete-everythingSkill
- data-pipelineSkill
- data-visualizationSkill
- debug-errorSkill
- debug-fe-be-integrationSkill
- debug-sentry-monitorSkill
- deploy-npmSkill
- deploy-verifySkill
- design-apiSkill
- design-canvasSkill
- design-emailSkill
- design-frontendSkill
- design-generative-artSkill
- design-mobile-firstSkill
- design-motionSkill
- design-prdSkill
- design-systemSkill
- design-themeSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 17
Read-only. Find where environments disagree in ways that cause "works on my machine", silent prod misbehavior, or leaked secrets.
- Very specific: line 36
Do not fire for "did I commit a key" → plan-secrets-audit.
- Very specific: line 37
Do not fire for "prove this laptop can run the suite" → workflow-environment-ready.
≈ “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.
Files
audit-env-parity — Environments that agree
Degree of freedom: MIXED — Phases 0–1 [HIGH freedom]; Phase 2
three-way name diff [LOW freedom — names only, never values].
Read-only. Find where environments disagree in ways that cause "works on my machine", silent prod misbehavior, or leaked secrets.
The classic outage: a new env var added locally, referenced in code, never set in prod — deploy is green, feature is broken.
Never print secret values. Present the gap matrix; do not change host config until approved.
This skill vs neighbors
| Skill | Owns |
| audit-env-parity (this) | Same keys exist (and mean the same) in every env |
workflow-environment-ready | Local machine can build/test/reach services |
plan-secrets-audit | Credential exposure in git / over-scoped keys |
plan-data-integrity | Destructive ops; staging pointing at prod is shared |
workflow-feature-flag | Flag rollout process, not "staging flag ≠ prod flag" |
Do not fire for "did I commit a key" → plan-secrets-audit.
Do not fire for "prove this laptop can run the suite" →
workflow-environment-ready.
How to reason
- Observe — quote the
process.env/import.meta.envread and whether the name exists in each env - Interpret — which runtime path breaks if that name is missing or public-prefixed?
- Classify — referenced-but-unset / naming drift / secret reuse / hardcoded / dead
- Severity — prod-missing or public-prefix secret = P0 / Critical
Worked example
Observe:
process.env.STRIPE_WEBHOOK_SECRETused inapp/api/stripe/route.ts; name absent from Vercel prod; present locally. Interpret: deploy is green; webhook verify fails only in prod. Classify: referenced-but-unset (prod). Severity: P0. Finding:STRIPE_WEBHOOK_SECRET| prod absent | P0 | set the name; never print the value
Phase 0 — Enumerate environments and sources [HIGH freedom]
- Envs: local, preview/staging, prod
- Sources:
.env*,.env.example, Vercel/Supabase/Fly dashboards, CI secrets, runtime config - Demanded set: every
process.env.X/import.meta.env/ config object read
Phase 1 — Parity and correctness [HIGH freedom]
Referenced-but-unset — Code reads it; an env that runs that path lacks it.
P0 if prod-missing. Diff .env.example against real usage.
Set-but-unreferenced — Dead vars. Low severity; they hide real config.
Naming drift — API_URL vs NEXT_PUBLIC_API_URL vs VITE_API_URL.
Public prefixes shipping a secret → Critical; hand to plan-secrets-audit.
Value drift that invalidates staging — Flags, timeouts, model names that make staging a different app than prod.
Hardcoded-should-be-config — URLs, regions, magic values in code. Prod pointing at a dev resource (or reverse).
Secret reuse — Same secret across dev/staging/prod (a dev leak is prod). Prod secrets reachable from a dev context.
Service targeting — Staging DB/bucket/queue must not be prod
(plan-data-integrity if a test would hit real data).
Phase 2 — Three-way gap [LOW freedom — names only]
Diff names only (never values) between code-demands × local-has × prod-has. A name present in all three with unknown value mismatch is still a manual review flag.
Definition of Done
- Envs + sources enumerated
- Code-referenced keys extracted
- Every referenced key checked in every env that runs it
.env.exampledrift flagged- Naming + public-prefix leaks identified
- Flag/value drift + hardcoded config found
- Cross-env secret reuse + staging→prod services checked
- Three-way gap produced with no secret values
- Nothing changed without approval
Self-critique before reporting [LOW freedom — do not skip]
- No secret values — names and present/absent only
- Evidenced — code read + env-has, not "probably set on Vercel"
- Severity justified — P0 = prod-missing on a live path
- Right owner — committed key →
plan-secrets-audit; staging→prod data →plan-data-integrity - Nothing changed until approved
Output format
- Parity matrix — key × env (present/absent/unknown) + demanded-by-code
- Findings — missing/dead/misnamed/leaked-prefix/hardcoded/drift
- Secret handoff —
plan-secrets-audit - Fix plan — prod-missing first, then leaks, then drift
Related
workflow-environment-ready— local preflightplan-secrets-audit— exposure / rotationplan-data-integrity— staging hitting prodplan-backup-dr— reconstructability of config after lossworkflow-feature-flag— rollout, not parity
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
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.

