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.