What problem does it solve? Environment variables in Next.js projects often fail silently: a missing variable surfaces as undefined deep in a page render, secrets get committed accidentally, and .gitignore rules for .env files break in subtle order-dependent ways. This Skill defines the policy for which env files are tracked, how variables are read through validated modules, and where secrets actually live per environment. ## Core Features & Use Cases - Validated env access: All process.env reads go through lib/env/server.ts or lib/env/client.ts, which parse a zod 4 schema at import so missing variables fail loudly at boot. - ESLint gate: eslint.dev-env.mjs restricts direct process.env access via no-restricted-properties, spread as the last element of the flat config so it cannot be silently overridden. - Gitignore policy: Defines which .env files are tracked (.env, .env.example, .env.test) versus ignored (.env.local, .env.production), verifiable with git check-ignore -v. - Secret placement guidance: Directs credentials to devcontainer .env.local, GitHub Actions secrets, or Vercel project variables, and pnpm env:cloud prints the block a cloud environment still needs. - Use Case: When adding a new API key, edit the zod schema in lib/env/server.ts, add a placeholder to .env.example, and import it — the build then fails up front if the variable is missing anywhere. ## Quick Start Add a new environment variable to this Next.js project following the env-and-secrets conventions and tell me where its secret value should live in each environment.
