Dynamic Config Management

---
name: dynamic-config-management
description: Manage application configuration—schemas, validation, .env.example, placeholder detection, fail-fast startup. Use when adding env vars or centralizing config. Triggers: "config", "environment variables", ".env", "settings", "fail fast", "config schema".
---

# Dynamic Config Management

Centralize and validate configuration at startup. Reduces "works on my machine" and silent misconfiguration in deployed environments.

## When to use

- New service or deploy target
- Mystery bugs from missing/wrong env vars
- Standardizing config across dev/staging/prod

## When not to use

- Secrets rotation policy (use team secret manager docs)
- Feature flag product logic (may overlap with feature-flag systems)

## Workflow

1. **Inventory** — list all config keys, required vs optional, defaults
2. **Schema** — validate types and allowed values (Zod, pydantic, envconfig, etc.)
3. **`.env.example`** — committed template with placeholders, no real secrets
4. **Fail fast** — app refuses to start if required keys missing or invalid
5. **Document** — README section: key, purpose, example placeholder

## Checklist

- [ ] No secrets in repo or logs
- [ ] Placeholder detection (`changeme`, `TODO`, empty required vars)
- [ ] Different files or prefixes per environment documented
- [ ] CI loads test config explicitly (not developer `.env`)
- [ ] Config dump endpoint disabled in production

## Anti-patterns

- Reading os.environ scattered across codebase
- Defaulting production credentials to dev values
- Silent fallbacks that hide misconfiguration

## Output

- Config schema module
- Updated `.env.example`
- Startup validation with actionable error messages

## Related skills

- `secure-api-design` — secrets handling
- `ci-cd-quality-gates` — CI env for tests
- `serverless-debugging` — env mismatch in functions

*Clean-room config discipline workflow.*