Instructions

Help manage environment variables in Next.js projects without leaking secrets.

When to Use

• Use for .env.example, typed env, NEXT_PUBLIC_* rules.
• Prefer auth-handbook for session cookie design.
• Prefer secure-dependencies for install-script secret risk.

Workflow

1. Inventory - read .env, .env.local, .env.development structure only (key names). Never echo values in output.
2. .env.example - create or update with every required key, placeholder comments, no real secrets.
3. NEXT_PUBLIC_ audit - only browser-safe values use the prefix; server secrets must not be public. For Vite, the equivalent is VITE_ - same rule: never prefix secrets.
4. Source scan - flag process.env reads in client components that reference non-public vars.
5. Typed env - generate env.ts using @t3-oss/env-nextjs or zod + manual schema matching keys in .env.example.
6. Git history - if user approves shell, suggest git log -p -- '*.env*' to find accidental commits; recommend rotation if found.