What problem does it solve? T3 projects often leak secrets through inconsistent .env loading, unvalidated process.env reads, and accidental exposure of server values in client bundles, tests, logs, or CI output. This Skill defines a single, portable set of rules for managing environment variables and keeping secret material out of code and evidence. ## Core Features & Use Cases - Single loader boundary: Standardizes one package-owned dotenvx with-env command with --overload, --quiet, and -f flags, forbidding nested loaders or in-code dotenv.config() calls. - Schema-validated env access: Requires an env.ts schema using @t3-oss/env-nextjs or @t3-oss/env-core with explicit server/client/runtimeEnv declarations before any variable is read. - Secret hygiene enforcement: Keeps secrets out of source, fixtures, snapshots, logs, and client bundles, and defers encryption, vault, and credential questions to the dotenvx-secrets and secrets-handling skills. - Use Case: When adding a new DATABASE_URL to a T3 app, apply this Skill to wire the dotenvx loader, declare the variable in the server schema, sync .env.example, and supply safe CI values without exposing real credentials. ## Quick Start Apply the T3 environment and secrets rules to review my env.ts schema, dotenvx scripts, and .env.example for the new variable I am adding.