manage-secrets-envlisted

# manage-secrets-env Every project has two kinds of structural decisions. Some are low-stakes — which branch naming, which directory layout — and a mistake costs a little friction. Some are high-stakes — where a database password lives, whether `.env` is tracked, whether a production token is in a build-time variable — and a mistake costs an incident. This skill owns the high-stakes slice: **secrets, environment variables, and the gitignore that protects them**. The low-stakes conventions (branches, directories, dep pinning, path portability) live in `project-conventions`. Splitting them this way means the operator can trigger the right depth of care for the right question. **The principle**: the safest default is the one the operator doesn't have to invent. When they ask *"where does my DB password go?"*, answer immediately, explain in one sentence, and offer to scaffold. ## State assumptions — before acting Before starting the procedure, write an explicit Assumptions block. Don't pick silently between interpretations; surface the choice. If any assumption is wrong or ambiguous, pause and ask — do not proceed on a guess. Required block: ``` Assumptions: - Environment tier: <dev | staging | prod — affects which bucket rules apply> - .env.example: <present | missing (drift check cannot run yet, operator must scaffold first)> - Tracked secrets: <none detected | FOUND — this is an incident; hand off to audit-security immediately, do not proceed with lifecycle work