agentleFS
Sign inStart free
DROOdotFOODROOdotFOO/agent-skills/skills/env-secrets-manager/SKILL.md

env-secrets-manager

Skill1 starsChanged 2 months agoMITView on GitHub

Environment variable hygiene, secret leak detection, and credential rotation workflows. TRIGGER when: working with .env files, secret management, credential rotation, pre-commit secret scanning, or investigating leaked credentials. DO NOT TRIGGER when: general config file editing, non-secret environment setup, or infrastructure provisioning (use relevant infra skill).

  • Reads credentials

We split this skill into the rules it gives an agent

8 rules. 5 are common, 0 are distinctive, and 3 are very specific to this project.

  • 5

    Common

    Most of the 7 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Common:

    Before pushing commits that touched env/config files

    line 31
  2. Common:

    When onboarding contributors who need safe env conventions

    line 33
  3. Common:

    When validating that no obvious secrets are hardcoded

    line 34
  4. Very specific:

    Update .env.example and .gitignore as needed

    line 41
  5. Common:

    Add or tighten pre-commit/CI secret scanning gates

    line 42
  6. Very specific:

    Use a secret manager as the production source of truth (never .env in prod)

    line 72
  7. Common:

    Keep dev env files local and gitignored

    line 73
  8. Very specific:

    Commit only .env.example, never .env

    line 76

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Env & Secrets Manager

Manage environment-variable hygiene and secrets safety across local development and production workflows. Covers auditing, leak detection, rotation, and preventive controls.

What You Get

  • Secret leak detection with regex-based scanning (staged files and git history)
  • Severity-based findings (critical/high/medium) with response playbook
  • Credential rotation workflows (AWS, Stripe, GitHub PAT, DB, JWT)
  • Cloud secret store integration guidance (Vault, AWS SM, Azure KV, GCP SM)
  • CI/CD secret injection patterns (GitHub Actions, GitLab CI)
  • Pre-commit detection setup (gitleaks, detect-secrets)

When to Use

  • Before pushing commits that touched env/config files
  • During security audits and incident triage
  • When onboarding contributors who need safe env conventions
  • When validating that no obvious secrets are hardcoded

Recommended Workflow

  1. Scan the repository for likely secret leaks (see references/secret-patterns.md)
  2. Prioritize critical and high findings first
  3. Rotate real credentials and remove exposed values
  4. Update .env.example and .gitignore as needed
  5. Add or tighten pre-commit/CI secret scanning gates

WRONG: secrets in code and examples

# WRONG: real credentials in .env.example
DATABASE_URL=postgres://admin:s3cret@prod.db.internal/myapp
STRIPE_SECRET_KEY=sk_live_abc123xyz

CORRECT: placeholders only

# CORRECT: .env.example with safe placeholders
DATABASE_URL=postgres://user:password@localhost/myapp_dev
STRIPE_SECRET_KEY=sk_test_REPLACE_ME

Common Pitfalls

MistakeWhy it's bad
Committing real values in .env.exampleExample files get pushed; real secrets in git history
Rotating one system but missing downstream consumersPartial rotation causes outages
Logging secrets during debuggingLogs persist in CI artifacts, observability platforms
Treating suspected leaks as low urgencyAutomated scrapers act within minutes of public exposure
Using echo on secrets in CI pipelinesEven with masking, secrets can leak via toJSON() or redirects

Best Practices

  1. Use a secret manager as the production source of truth (never .env in prod)
  2. Keep dev env files local and gitignored
  3. Enforce detection in CI before merge
  4. Re-test application paths immediately after credential rotation
  5. Commit only .env.example, never .env

Reference Docs

FileContents
references/secret-patterns.mdDetection regex by severity, response playbook
references/rotation-and-detection.mdValidation scripts, scanning tools, rotation workflow, pre-commit setup, cloud stores, CI/CD patterns

Cloud Secret Store Quick Reference

ProviderBest ForKey Feature
HashiCorp VaultMulti-cloud / hybridDynamic secrets, policy engine
AWS Secrets ManagerAWS-nativeLambda/ECS/EKS integration, auto RDS rotation
Azure Key VaultAzure-nativeManaged HSM, Azure AD RBAC
GCP Secret ManagerGCP-nativeIAM-based access, versioning
1PasswordDeveloper workflowsCLI (op), Connect server, SSH agent

Selection: Single cloud -> cloud-native store. Multi-cloud -> Vault. Developer/team -> 1Password or Doppler.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free