env-detection
# ClaudeWave: env-detection The env-detection skill systematically identifies all environment variables an application requires before deployment by scanning `.env` example files, source code patterns across multiple languages, framework configuration files, and dependency manifests. Use this skill when preparing applications for deployment, troubleshooting missing configuration errors, or auditing projects to ensure all required environment variables are properly documented and configured.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/env-detection && cp -r /tmp/env-detection/api/skills/env-detection ~/.claude/skills/env-detectionSKILL.md
# Environment Variable Detection
Identify all environment variables an application needs before deployment. Missing env vars are the most common cause of deployment failures.
## Detection sources (check in order)
### 1. `.env.example` / `.env.sample` / `.env.template`
Primary source. Read the file and extract every variable name and any inline comments describing its purpose.
```
DATABASE_URL=postgresql://user:pass@localhost:5432/db
REDIS_URL=redis://localhost:6379
API_KEY=your-api-key-here
SECRET_KEY=change-me
```
### 2. Source code patterns
Use `grep` across the repo root for these patterns:
| Pattern | Language |
|---------|----------|
| `process.env.VAR_NAME` | Node.js |
| `Deno.env.get("VAR_NAME")` | Deno |
| `os.environ["VAR_NAME"]` or `os.getenv("VAR_NAME")` | Python |
| `os.Getenv("VAR_NAME")` | Go |
| `ENV["VAR_NAME"]` or `ENV.fetch("VAR_NAME")` | Ruby |
| `env::var("VAR_NAME")` | Rust |
| `System.getenv("VAR_NAME")` | Java |
| `@Value("${VAR_NAME}")` | Spring |
### 3. Framework config files
| File | What to look for |
|------|-----------------|
| `next.config.js` / `next.config.mjs` | `env:` block, `NEXT_PUBLIC_*` prefixed vars |
| `nuxt.config.ts` | `runtimeConfig` block |
| `vite.config.ts` | `define` block, `VITE_*` prefixed vars |
| `docker-compose.yml` | `environment:` sections |
| `Dockerfile` | `ENV` and `ARG` directives |
| `settings.py` (Django) | `os.environ` calls |
| `config/*.yml` (Rails) | `<%= ENV["VAR"] %>` patterns |
### 4. Database/service URLs
Check dependency manifests for services that typically require connection URLs:
| Dependency | Expected env var |
|-----------|-----------------|
| `pg` / `sequelize` / `prisma` / `typeorm` | `DATABASE_URL` |
| `mongoose` / `mongodb` | `MONGODB_URI` |
| `ioredis` / `redis` | `REDIS_URL` |
| `@aws-sdk/*` | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION` |
| `stripe` | `STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET` |
| `@sendgrid/mail` | `SENDGRID_API_KEY` |
| `nodemailer` | `SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASS` |
| `@auth0/*` / `next-auth` | `AUTH_SECRET`, `AUTH_URL`, provider-specific keys |
## Classification
Classify each detected variable:
| Category | Examples | Required for deploy? |
|----------|---------|---------------------|
| **Infrastructure** | `DATABASE_URL`, `REDIS_URL`, `PORT` | Yes |
| **Secrets** | `API_KEY`, `SECRET_KEY`, `JWT_SECRET` | Yes |
| **Service URLs** | `NEXT_PUBLIC_API_URL`, `WEBHOOK_URL` | Yes (but values differ per environment) |
| **Build-time** | `NEXT_PUBLIC_*`, `VITE_*` | Yes (must be set during build) |
| **Optional/Debug** | `LOG_LEVEL`, `DEBUG`, `NODE_ENV` | No (has sensible defaults) |
## Build-time vs runtime
This distinction matters for Dockerfiles:
- **Build-time**: Set as `ARG` in Dockerfile, passed via `--build-arg` or `args:` in compose. Includes `NEXT_PUBLIC_*`, `VITE_*`, and any var used during `npm run build`.
- **Runtime**: Set as `ENV` in Dockerfile or `environment:` in compose. Includes `DATABASE_URL`, `PORT`, API keys.
## Output format
After detection, report:
1. List of all detected env vars with their source (`.env.example`, source code, framework config)
2. Classification (infrastructure, secret, service URL, build-time, optional)
3. Which vars are missing values (need user input)
4. Which vars have safe defaults (e.g. `PORT=3000`, `NODE_ENV=production`)
5. Which vars are build-time and must be in Dockerfile `ARG` directives
## Related Skills
- **`pre-deploy-checklist`** — Uses env detection results to validate deployment readiness
- **`dockerfile-generation`** — Build-time env vars identified here need `ARG` directives in the DockerfileReference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Generate docker-compose.yml for multi-service setups including databases, caches, and service dependencies. Use when the app needs a database, cache, message broker, or has multiple independently deployable services.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.