---
name: env-handler
description: Manage environment variables securely. Handles distinction between .env (template) and .env.local (secrets).
---
# Environment Variable Handler
## Core Rules
1. **NO `.env.example`**: Do not create this file. Use `.env` as the template.
2. **Secrets in `.env.local`**: Actual sensitive values must live in `.env.local` (git-ignored).
3. **Placeholders**: Every variable in `.env.local` MUST have a corresponding entry in `.env`.
- If sensitive: `KEY=""`
- If public/common: `KEY="default_value"`
## Instructions
### 1. Adding a New Sensitive Variable
When you need to add a secret (e.g., `REPLICATE_API_TOKEN`):
1. **Update `.env`**:
Add the variable with an empty string value.
```bash
# .env
REPLICATE_API_TOKEN=""
```
2. **Ask the User**:
Explicitly request the user to add the actual value to their local secrets file.
> "I have added `REPLICATE_API_TOKEN` to your `.env` file. Please open `.env.local` and add the actual token: `REPLICATE_API_TOKEN=your_token_here`"
### 2. Adding a Non-Sensitive Variable
When adding a public or configuration variable (e.g., `NEXT_PUBLIC_APP_URL`):
1. **Update `.env`**:
Add the variable with its default or development value.
```bash
# .env
NEXT_PUBLIC_APP_URL="http://localhost:3000"
```
### 3. Reading Variables
- Server-side: `process.env.KEY`
- Client-side: `process.env.NEXT_PUBLIC_KEY`
## Checklist
- [ ] Is the variable in `.env`?
- [ ] If sensitive, is the value in `.env` empty?
- [ ] Did I ask the user to update `.env.local`?