core-setup-env-and-secrets

name	core-setup-env-and-secrets
description	Use when setting up or changing project configuration, local environments, CI/CD credentials, or secrets—separate configuration from secrets, validate at startup, use least-privilege delivery, prevent leaks, and plan rotation.

Environments & Secrets

Config and secrets done right before the first feature exists.

Separate configuration from secrets

• Configuration is safe to describe and version: feature mode, public URL, region, limits, and log level. Secrets grant access: credentials, signing keys, tokens, private endpoints, and encryption material. Treat the second class as toxic to source control and logs.
• Define one typed configuration schema at process startup. Validate required values, formats, allowed environments, and unsafe combinations before accepting traffic; fail clearly without echoing values.
• Commit .env.example with variable names, safe examples, owner/purpose, and setup notes. Never commit .env, private keys, production exports, or generated credential files.

Delivery rules

• Give local developers a one-command bootstrap that retrieves permitted development values from the chosen secret manager or password-manager workflow. Do not copy production secrets locally.
• Use the platform or cloud secret manager for deployed environments. CI receives environment- scoped, masked values; prefer workload identity/OIDC and short-lived credentials over stored cloud access keys.
• Keep local, preview, staging, and production separate. Preview uses isolated credentials and data; production access is protected, least-privilege, and never an implicit fallback.
• Name variables consistently (SERVICE_API_KEY, DATABASE_URL); one variable has one purpose. Do not encode JSON blobs of unrelated settings or use environment names to hide behavior.

Leak and rotation response

• Scan pre-commit and CI for credentials; redact values from logs, screenshots, error reports, and support exports. A false-positive allowlist is narrow, reviewed, and expires.
• If a secret appears in a commit, artifact, log, or chat: revoke/rotate it first, identify use, update consumers, then remove historical exposure where practical. Deleting the file alone is not remediation.
• Assign an owner, scope, expiry/rotation expectation, and recovery procedure to every production secret. Remove unused values and access promptly.

core-build-secure-coding owns code-level secret hygiene; core-setup-ci-skeleton and core-ship-release-pipeline consume secrets safely. This skill establishes the environment contract they rely on.