Env hygiene

Skill Hayatelin/devsecops-skills/skills/env-hygiene

A security skills pack for Claude Code, Cursor, Codex and Gemini CLI: secrets pre-flight, dependency audit, secret rotation, STRIDE threat modeling, secure code review, Dockerfile hardening and env hygiene.

Install

npx -y skills add Hayatelin/devsecops-skills --skill env-hygiene

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Keep secrets and config clean: .env handling, .gitignore coverage, never committing secrets, and 12-factor config. Trigger when the user says "check my .env setup", "am I leaking config", "set up environment variables", or when adding config, a new env var, or onboarding a repo.

SKILL.md

3.0 KB, as published. Nobody here has run it

When to use

Setting up or reviewing how a project handles configuration and secrets.
Adding a new environment variable or config value.
Onboarding/auditing a repo for "is anything secret about to be committed?"
Separating dev/staging/prod configuration.

Process

Inventory config sources: .env, .env.*, config files, CI variables, and anything hardcoded in source.
Confirm .gitignore actually covers every secret-bearing file (checklist below).
Check git history for already-committed secrets (git log -p, or run gitleaks detect). If any are found, treat as a leak → use the secret-rotation skill (rotate first).
Verify a non-secret .env.example exists so contributors know what to set.
Confirm dev and prod config are separated and prod secrets come from a manager, not a file in the repo.
Fix gaps and document the config contract.

Checklist

.gitignore includes .env, .env.*, *.local, secrets/, *.pem, *.key, *.pfx, credential JSONs.
.env.example IS committed (keys only, dummy/empty values) — and the real .env is NOT.
No secrets hardcoded in source, configs, CI YAML, or client-side bundles (anything shipped to the browser is public).
Secrets read from process.env / os.environ — never inlined.
Git history is clean of credentials (scanned, not assumed).
Prod secrets live in a secrets manager (Vault, AWS/GCP Secrets Manager, Doppler) or the CI/host's encrypted secret store — not in a .env checked into the repo.
Dev/staging/prod use separate credentials; a leaked dev key can't touch prod.
.env files are not baked into Docker images or build artifacts (see dockerfile-hardening).

How to fix — 12-factor config

Store config in the environment, not in code. One codebase, many deploys, config injected per environment.
Add the missing .gitignore entries, then git rm --cached <file> any secret already tracked (and rotate it if it was ever pushed).
Create/commit .env.example with every key documented and no real values.
Move production secrets to a manager and inject at deploy/runtime; give each environment its own credentials with least privilege.
Add a pre-commit secret scanner (gitleaks, secscan) and enable push protection so a secret can't get committed again.
Provide a one-line setup note: cp .env.example .env then fill values locally.

Report back

Summarize: what config sources exist, whether .gitignore fully covers secrets, whether .env.example is present, and the result of the history scan. List exactly what you fixed and any secret found in history (flag loudly — that needs rotation, not just deletion). End with a "config hygiene: clean / N gaps" verdict.