handling-secrets-safelylisted

# Handling Secrets Safely The generic posture - secrets live outside repos and gitignored, never echo a secret, rotate any leak - is assumed. This skill is the mechanics that stop a well-intentioned command from disclosing a value anyway. Every rule below is a real incident distilled to a check. ## When to use - Probing or reading a credential-bearing file: `.mcp.json`, `.env*`, `*.pem`, `~/.git-credentials`, `~/.netrc`, a secret store. - Clearing a "no secrets committed" or security-sweep verdict. - Using a secret in a command (a token in an API call, a password in a connection string). - Writing config that must reference a secret. ## When NOT to use - Ordinary files with no credential content. - The high-level secret POLICY (where secrets live, how rotation works) - that belongs in the personal layer / a project CLAUDE.md; this skill is only the leak-mechanics. ## Rules ### 1. A "no secrets" verdict must scan git HISTORY, not the working tree A secret added then removed still lives on the remote and in every clone. Scan all of history - `gitleaks git --log-opts=--all` (or `git log -p -S'<pattern>' --all`) - a clean working tree is NOT proof. A secret found in history is already leaked: rotate it; deleting the file does not un-leak it. ### 2. On a credential-bearing file, use boolean/count probes ONLY `grep -c`, `wc -l`, `stat`, `jq 'keys'` / `jq 'paths'` - never a content transform. A `sed`/`awk`/`cut`/regex-substring that fails to match prints the raw line VERBA