All tools
SkillCurated · reviewed
Env Config Skill
Updated Jul 7, 2026
A Claude Code skill that audits environment and configuration files: flags missing required variables, unsafe default values, secrets hard-coded in source, and .env.example sync gaps. Each finding includes severity and a concrete fix.
What it does
- /check-env
Audit .env.example and config files for missing vars, unsafe defaults, secret leaks, and sync gaps.
- /check-env <file>
Audit a specific environment or config file by name or pasted content.
Files (1)
SKILL.mdprimary · markdown · 4.2 KB
# Env Config Skill --- slug: env-config-skill version: 1.0.0 category: engineering command: /check-env --- ## What it does Audits `.env`, `.env.example`, and application config files for four classes of problems: missing required variables, unsafe or insecure default values, secrets embedded in source code, and drift between `.env.example` and the actual `.env` in use. Every finding is rated by severity (Critical / High / Medium / Low) and includes a concrete fix. ## Trigger Use this skill when asked to audit, check, or review environment variables or config. Typical invocations: - "Check our .env.example — are we missing anything?" - "Audit this config for secret leaks" - `/check-env` in Claude Code - `/check-env <file>` to target a specific config file ## Input Provide one or more of: 1. The `.env.example` or `.env` file content (redact real secret values before pasting) 2. The application config files (e.g. `config.ts`, `settings.py`, `application.yml`) 3. A list of variables the app is known to require 4. The `.gitignore` if you want a check that `.env` is properly excluded Do not paste real secrets. Redact values to `<REDACTED>` — the skill audits structure and names, not values. ## Method Run four passes: ### Pass 1 — Missing required variables Compare what `.env.example` declares against what application code references (via `process.env.X`, `os.environ["X"]`, etc.). Flag any variable referenced in code but absent from `.env.example`. ### Pass 2 — Unsafe defaults Look for dangerous default values: - `DEBUG=true` or `NODE_ENV=development` in a file likely to reach production - Empty strings for secrets (`JWT_SECRET=""`) - Placeholder strings that look like real values (`API_KEY=changeme`, `DB_PASSWORD=root`) - Ports or hosts that expose services on 0.0.0.0 without comment ### Pass 3 — Secrets in source Scan config files for hard-coded credentials, tokens, or API keys. Patterns: - Long alphanumeric strings assigned to variables named `SECRET`, `TOKEN`, `KEY`, `PASS`, `PWD` - Bearer tokens or AWS key patterns in code (not in .env) - Base64 blobs that decode to key material ### Pass 4 — .env.example sync Flag variables present in `.env.example` but never referenced in code (dead config), and variables present in `.env` but absent from `.env.example` (undocumented secret). ## Output format Produce a findings list sorted by severity, then a **Summary** table: ``` ## Findings **[Critical] JWT_SECRET has an empty default** (Pass 2) File: .env.example, line 12 Fix: Set JWT_SECRET to a placeholder like `JWT_SECRET=<generate with: openssl rand -hex 32>` **[High] DATABASE_URL referenced in db.ts but absent from .env.example** (Pass 1) File: src/lib/db.ts:4 Fix: Add `DATABASE_URL=postgres://user:password@localhost:5432/mydb` to .env.example ## Summary | Severity | Count | |----------|-------| | Critical | 1 | | High | 1 | | Medium | 0 | | Low | 0 | ``` ## Example output ``` ## Findings [Critical] STRIPE_SECRET_KEY has a placeholder that looks like a real key format File: .env.example, line 8: STRIPE_SECRET_KEY=sk_live_XXXXXXXXXXXXXXXXXXXX Fix: Use a clearly fake value: STRIPE_SECRET_KEY=<your Stripe secret key> Why: The `sk_live_` prefix matches the real Stripe live-key pattern; a developer may not notice it is fake. [High] SESSION_SECRET uses the default string "secret" (unsafe for production) File: config/session.ts, line 3: secret: process.env.SESSION_SECRET ?? 'secret' Fix: Remove the fallback; throw at startup if SESSION_SECRET is unset in production. [Medium] REDIS_URL is in .env but not in .env.example — undocumented dependency Fix: Add REDIS_URL=redis://localhost:6379 to .env.example with a comment explaining its purpose. [Low] LOG_LEVEL is declared in .env.example but never read in application code Fix: Remove it, or wire it up to the logger initialisation. ## Summary | Severity | Count | |----------|-------| | Critical | 1 | | High | 1 | | Medium | 1 | | Low | 1 | ``` ## Commands (Claude Code) - `/check-env` — Audit the pasted .env.example and config files for all four issue classes. - `/check-env <file>` — Audit a specific environment or config file by name or pasted content.