← ClaudeAtlas

env-config-contractlisted

Use when the user asks to consolidate, type, validate, migrate, or debug environment variables and configuration, especially duplicate env reads, silent defaults, client/server leakage, or inconsistent build and runtime config.
YosefHayim/dufflebag · ★ 2 · AI & Automation · score 68
Install: claude install-skill YosefHayim/dufflebag
# Environment Configuration Contract Create one fail-loud contract for configuration crossing process, build, deployment, or client boundaries. Consumers receive decoded domain values rather than reading raw environment variables independently. ## Safety - Read repository and deployment instructions before changing config. Inventory first; do not remove legacy reads until every consumer and environment is accounted for. - Never print secret values, commit real `.env` files, expose server values to client bundles, or broaden public prefixes to make a build pass. - Required values fail with actionable key names and remediation, not secret contents. Defaults are allowed only for genuinely optional behavior. - Preserve build-time, runtime, server, client, test, worker, and deployment-provider boundaries. One contract can have explicit projections; it must not pretend those trust zones are identical. ## Workflow 1. Search all source, scripts, tests, manifests, CI, containers, hosting config, examples, and docs for environment and config reads. Record key, consumer, phase, trust zone, requiredness, default, and current validator. 2. Reconcile aliases and conflicting semantics. Choose canonical domain names and document migrations before editing consumers. 3. Use the repository's schema system as the single decoder. Define required, optional, defaulted, enum, URL, number, boolean, and secret fields inline with their constraints and descriptions. 4. Decode once at the earliest t