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 workflows>