Environment and configuration management skill. Activates when user needs to manage dev/staging/prod configs, validate environment parity, design feature flags, or plan A/B test rollouts. Ensures config consistency, secret safety, and environment drift detection. Triggers on: /godmode:config, "manage environments", "feature flags", "config validation", "A/B test setup", or when ship skill needs environment verification.
From godmodenpx claudepluginhub arbazkhan971/godmodeThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
/godmode:configMap all configuration sources and environments:
# Find config files
find . -name "*.env*" -o -name "*.config.*" -o -name "*.yml" -o -name "*.yaml" -o -name "*.toml" -o -name
"*.ini" | grep -v node_modules | grep -v .git
# Check for environment-specific files
find . -name "*development*" -o -name "*staging*" -o -name "*production*" -o -name "*prod*" -o -name "*dev*" |
grep -v node_modules | grep -v .git
CONFIG INVENTORY:
Environments: <dev | staging | prod | custom>
Config sources:
- Environment variables: <list of .env files>
- Config files: <list of config files>
- Secret managers: <vault/AWS SSM/GCP Secret Manager/none>
- Feature flag provider: <LaunchDarkly/Unleash/custom/none>
Config format: <JSON | YAML | TOML | dotenv | mixed>
Total config keys: <N>
Secret keys: <N>
Non-secret keys: <N>
Compare configurations across environments to detect drift:
PARITY CHECK:
| Config Key | Dev | Staging | Prod |
|--|--|--|--|
| DATABASE_URL | ✓ | ✓ | ✓ |
| REDIS_URL | ✓ | ✓ | ✓ |
│ LOG_LEVEL │ debug│ info │ warn │ ← EXPECTED DIFF
│ FEATURE_NEW_UI │ true │ true │ false│ ← EXPECTED DIFF
│ MAX_CONNECTIONS │ 10 │ 50 │ 100 │ ← EXPECTED DIFF
| API_TIMEOUT_MS | 5000 | 5000 | 5000 |
│ SENTRY_DSN │ ✓ │ ✓ │ ✗ │ ← MISSING IN PROD
│ NEW_SERVICE_URL │ ✓ │ ✗ │ ✗ │ ← ONLY IN DEV
CRITICAL DRIFT (must fix):
- Keys present in one env but missing in another (likely deployment failure)
- Type mismatches (string in dev, number in prod)
- Secret keys with placeholder values in non-dev environments
EXPECTED DRIFT (document and accept):
- Log levels (debug in dev, warn in prod)
- Connection pool sizes (scaled per environment)
- Feature flags (intentional per-environment rollout)
- Debug/profiling settings (dev-only)
SUSPICIOUS DRIFT (investigate):
- Different values for same key with no documented reason
- Timeout or retry values that differ without scaling justification
- Third-party service URLs that don't match environment tier
Generate or verify a validation schema for all configuration:
// config/schema.ts — Single source of truth for all config keys
const configSchema = {
DATABASE_URL: {
type: 'string',
required: true,
format: 'uri',
For EVERY config key, validate:
1. PRESENCE — Required keys exist in every environment
2. TYPE — Value matches expected type (string, number, boolean, URL, etc.)
3. FORMAT — Value matches pattern (URLs, email, API key formats)
4. RANGE — Numeric values within acceptable bounds
5. SENSITIVITY — Sensitive values not hardcoded or committed to git
6. CONSISTENCY — Same key has same type across all environments
// Validate config on application startup — fail fast
function validateConfig(env: Record<string, string>): void {
const errors: string[] = [];
for (const [key, schema] of Object.entries(configSchema)) {
const value = env[key];
if (schema.required && !value) {
IF config change breaks health check: rollback immediately. WHEN feature flag stale >30 days: schedule removal.
Design and manage feature flags for controlled rollouts:
FLAG TYPES:
1. RELEASE FLAG — Gate new features (temporary, remove after full rollout)
Example: FEATURE_NEW_CHECKOUT=true
Lifecycle: Create → Dev → Staging → % Prod → 100% Prod → Remove flag
2. EXPERIMENT FLAG — A/B test with measurement
Example: EXPERIMENT_PRICING_V2={variant: "B", percentage: 25}
Lifecycle: Create → Configure variants → Run → Measure → Pick winner → Remove
3. OPS FLAG — Control operational behavior
Example: OPS_MAINTENANCE_MODE=false
Lifecycle: Create → Toggle during incidents → Keep permanently
4. PERMISSION FLAG — Gate features by user segment
Example: PERMISSION_BETA_FEATURES=["user_123", "org_456"]
interface FeatureFlag {
name: string; // SCREAMING_SNAKE_CASE
type: 'release' | 'experiment' | 'ops' | 'permission';
description: string; // What this flag controls
owner: string; // Team or person responsible
createdAt: string; // ISO date
Every flag: owner + expiry date. Release flags >30 days at 100%: remove flag, keep code. Experiment flags >14 days: conclude, pick winner. Dead flags (no code refs): delete. Keep total under 20 for small teams. Weekly stale flag report.
Design controlled experiments with statistical rigor:
EXPERIMENT PLAN:
Name: <experiment_name>
Hypothesis: "Changing <X> will improve <metric> by <expected_delta>"
Primary metric: <conversion_rate | revenue | engagement | latency | etc.>
Secondary metrics: <list of guardrail metrics to monitor>
Minimum detectable effect: <smallest meaningful improvement, e.g., 2%>
Statistical significance: <p-value threshold, default 0.05>
Required sample size: <calculated from MDE and baseline>
Variants:
Control (A): <current behavior>
Treatment (B): <new behavior>
[Treatment (C)]: <optional additional variant>
Traffic split: <50/50 | 80/20 | custom>
Phase 1: Internal (100%, 2-3 days, catch bugs). Phase 2: Canary (1-5%, 24-48h, verify no regressions). Phase 3: Controlled (10% -> 25% -> 50%, 1-2 weeks per increment, gather statistical significance).
Verify secrets are handled safely across all environments:
SECRET AUDIT:
| Check | Status | Finding |
|--|--|--|
| .env in .gitignore | PASS/FAIL | <detail> |
| No secrets in code | PASS/FAIL | <files with hardcoded> |
| No secrets in logs | PASS/FAIL | <log statements to fix> |
| Secrets rotatable | PASS/FAIL | <non-rotatable secrets> |
| Secrets have expiry | PASS/FAIL | <non-expiring secrets> |
| Dev ≠ prod secrets | PASS/FAIL | <shared secrets> |
| Secret manager in use | PASS/FAIL | <recommendation> |
| Encryption at rest | PASS/FAIL | <unencrypted stores> |
CONFIG AUDIT — <project>
Environments: <N> configured
Total config keys: <N>
Sensitive keys: <N>
PARITY:
Keys in all envs: <N>/<total>
Missing keys: <N> (CRITICAL)
Expected drift: <N> (documented)
Suspicious drift: <N> (needs investigation)
VALIDATION:
Schema coverage: <X>% of keys have validation
docs/config/<project>-config-audit.md"config: <project> — <verdict> (<N> keys, <N> flags, <N> issues)"| Flag | Description |
|---|---|
| (none) | Full config audit — parity, validation, secrets, flags |
--parity | Environment parity check only |
--validate | Config validation schema check only |
Never ask to continue. Loop autonomously until all environments are audited and drift is resolved.
timestamp environments total_keys missing_keys secret_issues flags_stale verdict
On activation, automatically detect all configuration without asking:
AUTO-DETECT:
1. Config files:
find . -name "*.env*" -o -name "*.config.*" -o -name "*.yml" \
-o -name "*.yaml" -o -name "*.toml" -o -name "*.ini" \
| grep -v node_modules | grep -v .git
2. Environment-specific files:
find . -name "*development*" -o -name "*staging*" -o -name "*production*" \
-o -name "*prod*" -o -name "*dev*" | grep -v node_modules
3. Secret references:
grep -r "SECRET\|API_KEY\|PASSWORD\|TOKEN\|PRIVATE" \
--include="*.env*" --include="*.config.*" -l
4. Feature flag provider:
Print on completion: Config: {config_key_count} keys across {env_count} environments. Secrets: {secret_count} (all in secret manager: {secret_mgr_status}). Drift: {drift_count} keys differ. Validation: {validation_status}. Feature flags: {flag_count}. Verdict: {verdict}.
Log every configuration operation to .godmode/config-results.tsv:
iteration task environment keys_total secrets_count drift_detected validation_status status
1 inventory production 45 12 0 passing audited
2 inventory staging 45 12 3 passing drift_found
3 secrets all 0 12 0 migrated migrated
4 validation all 45 0 0 zod_schema configured
Columns: iteration, task, environment, keys_total, secrets_count, drift_detected, validation_status, status(audited/drift_found/migrated/configured/failed).
All keys inventoried. Secrets in secret manager. Startup validation fails fast. Drift detected and explained.
Flags have expiry + cleanup plans. Typed config parsing (no raw process.env). Config changes auditable.
| Failure | Action |
|---|---|
| App fails to start after config change | Check validation errors for specific key. Compare with previous working config. |
| Secret rotation breaks app | Test rotation in staging first. Validate new secret before revoking old. |
| Config drift between envs | Run drift detection. Document intentional drift, fix accidental. |
KEEP if: improvement verified. DISCARD if: regression or no change. Revert discards immediately.
Stop when: target reached, budget exhausted, or >5 consecutive discards.