Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
You need to work with environment variables or secrets in a Claude Code session without exposing their values.
The task involves validating, loading, or auditing secrets while keeping them out of logs, diffs, and assistant context.
You want a secure-by-default workflow built around Varlock instead of direct .env inspection.
Core Principle: Secrets Never Exposed
When working with Claude, secrets must NEVER appear in:
Terminal output
Claude's input/output context
Log files or traces
Git commits or diffs
Error messages
This skill ensures all sensitive data is properly protected.
CRITICAL: Security Rules for Claude
Rule 1: Never Echo Secrets
# ❌ NEVER DO THIS - exposes secret to Claude's contextecho$CLERK_SECRET_KEYcat .env | grep SECRET
printenv | grep API
# ✅ DO THIS - validates without exposing
varlock load --quiet && echo"✓ Secrets validated"
Rule 2: Never Read .env Directly
# ❌ NEVER DO THIS - exposes all secretscat .env
less .env
Read tool on .env file
# ✅ DO THIS - read schema (safe) not valuescat .env.schema
varlock load # Shows masked values
Rule 3: Use Varlock for Validation
# ❌ NEVER DO THIS - exposes secret in errortest -n "$API_KEY" &&
varlock load
echo
"Key: $API_KEY"
# ✅ DO THIS - Varlock validates and masks
# Output shows: API_KEY 🔐sensitive └ ▒▒▒▒▒
Rule 4: Never Include Secrets in Commands
# ❌ NEVER DO THIS - secret in command history
curl -H "Authorization: Bearer sk_live_xxx" https://api.example.com
# ✅ DO THIS - use environment variable
curl -H "Authorization: Bearer $API_KEY" https://api.example.com
# Or better: varlock run -- curl ...
Quick Start
Installation
# Install Varlock CLI
curl -sSfL https://varlock.dev/install.sh | sh -s -- --force-no-brew
# Add to PATH (add to ~/.zshrc or ~/.bashrc)export PATH="$HOME/.varlock/bin:$PATH"# Verify
varlock --version
Initialize Project
# Create .env.schema from existing .env
varlock init
# Or create manuallytouch .env.schema
Schema File: .env.schema
The schema defines types, validation, and sensitivity for each variable.
# Check all variables (safe - masks sensitive values)
varlock load
# Quiet mode (no output on success)
varlock load --quiet
# Check specific environment
varlock load --env=production
Running Commands with Secrets
# Inject validated env into command
varlock run -- npm start
varlock run -- node script.js
varlock run -- pytest
# Secrets are available to the command but never printed
Checking Schema (Safe)
# Schema is safe to read - contains no valuescat .env.schema
# List expected variables
grep "^[A-Z]" .env.schema
Common Patterns
Pattern 1: Validate Before Operations
# Always validate environment first
varlock load --quiet || {
echo"❌ Environment validation failed"exit 1
}
# Then proceed with operation
npm run build
Pattern 2: Safe Secret Rotation
# 1. Update secret in external source (1Password, AWS, etc.)# 2. Update .env file manually (don't use Claude for this)# 3. Validate new value works
varlock load
# 4. If using GitHub Secrets, sync (values not shown)
./scripts/update-github-secrets.sh
Pattern 3: CI/CD Integration
# GitHub Actions - secrets from GitHub Secrets-name:Validateenvironmentenv:DATABASE_URL:${{secrets.DATABASE_URL}}API_KEY:${{secrets.API_KEY}}run:varlockload--quiet
Pattern 4: Docker Integration
# Install Varlock in container
RUN curl -sSfL https://varlock.dev/install.sh | sh -s -- --force-no-brew \
&& ln -s /root/.varlock/bin/varlock /usr/local/bin/varlock
# Validate at container start
CMD ["varlock", "run", "--", "npm", "start"]
# ✅ Safe approach - check presence and format
varlock load # Validates types and required fields# Check if key has correct prefix (without showing value)
varlock load 2>&1 | grep -E "(CLERK|AUTH)"# ❌ Never doprintenv | grep KEY
When User Asks to "Update a secret"
Claude should respond:
"I cannot directly modify secrets for security reasons. Please:
1. Update the value in your .env file manually
2. Or update in your secrets manager (1Password, AWS, etc.)
3. Then run `varlock load` to validate
I can help you update the .env.schema if you need to add new variables."
When User Asks to "Show me the .env file"
Claude should respond:
"I won't read .env files directly as they contain secrets. Instead:
- Run `varlock load` to see masked values
- Run `cat .env.schema` to see the schema (safe)
- I can help you modify .env.schema if needed"
External Secret Sources
1Password Integration
# In .env.schema# @type=string @sensitive
API_KEY=exec('op read "op://vault/item/field"')
AWS Secrets Manager
# In .env.schema# @type=string @sensitive
DB_PASSWORD=exec('aws secretsmanager get-secret-value --secret-id prod/db')
Environment-Specific Values
# In .env.schema# @type=url
API_URL=env('API_URL_${NODE_ENV}', 'http://localhost:3000')
Troubleshooting
"varlock: command not found"
# Check installationls ~/.varlock/bin/varlock
# Add to PATHexport PATH="$HOME/.varlock/bin:$PATH"# Or use full path
~/.varlock/bin/varlock load
"Schema validation failed"
# Check which variables are missing/invalid
varlock load # Shows detailed errors# Common fixes:# - Add missing required variables to .env# - Fix type mismatches (port must be number)# - Check string prefixes match schema
"Sensitive value exposed in logs"
# 1. Rotate the exposed secret immediately# 2. Check .env.schema has @sensitive annotation# 3. Ensure using varlock commands, not echo/cat# Add missing sensitivity:# Before: API_KEY=# After: # @type=string @sensitive# API_KEY=
