agentleFS
Sign inStart free
scayverscayver/marketing-skills/skills/env-secrets-manager/SKILL.md

env-secrets-manager

Skill8 starsChanged 5 months agoMITView on GitHub

Use this skill when the user wants to manage environment variables, secrets, API keys, .env files, deployment configuration, secret rotation, credential hygiene, local development setup, or secret leakage prevention. Trigger phrases include ".env," "environment variables," "secrets manager," "API key safety," "rotate secrets," "deployment env," "credential leak," and "secret hygiene."

  • Reads credentials

We split this skill into the rules it gives an agent

17 rules. 0 are common, 11 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 6

    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. Distinctive:

    Write in active voice.

    line 15
  2. Distinctive:

    Use short sentences and plain language.

    line 16
  3. Very specific:

    Use .marketing-os/product-context.md when it exists.

    line 18
  4. Distinctive:

    Never print, copy, transform, or expose real secrets in the response.

    line 19
  5. Very specific:

    Do not suggest committing .env files that contain credentials.

    line 21
  6. Distinctive:

    Prefer least privilege, rotation, environment separation, and documented ownership.

    line 22
  7. Distinctive:

    Do not use em dashes, hashtags, emojis, or filler closings.

    line 23
  8. Very specific:

    Use this skill to keep credentials, API keys, tokens, webhook secrets, deployment variables, and local .env files organized and safe.

    line 28
  9. Very specific:

    Commit .env.example with variable names and safe placeholder values.

    line 65
  10. Very specific:

    Do not commit real .env files.

    line 66
  11. Very specific:

    Add .env* to .gitignore, except .env.example if the project needs it.

    line 67
  12. Distinctive:

    Keep production secrets in the deployment platform or managed secrets store.

    line 68
  13. Distinctive:

    Use different keys for development, staging, and production.

    line 69
  14. Distinctive:

    Update local, CI, staging, and production secret stores.

    line 77
  15. Distinctive:

    Search recent commits and logs for exposed values.

    line 80
  16. Distinctive:

    Document the incident and prevention step.

    line 81
  17. Distinctive:

    Do not paste the exposed secret into tickets, chat, commits, or documentation.

    line 83

“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

Environment Secrets Manager

Mandatory Content Standards

  • Write in active voice.
  • Use short sentences and plain language.
  • Address the user as "you" and "your."
  • Use .marketing-os/product-context.md when it exists. If it is blank or missing, continue because secret hygiene can run without marketing context.
  • Never print, copy, transform, or expose real secrets in the response.
  • Redact secrets as ***REDACTED***.
  • Do not suggest committing .env files that contain credentials.
  • Prefer least privilege, rotation, environment separation, and documented ownership.
  • Do not use em dashes, hashtags, emojis, or filler closings.
  • End every full deliverable with one specific next step.

Objective

Use this skill to keep credentials, API keys, tokens, webhook secrets, deployment variables, and local .env files organized and safe.

This skill supports marketing automation projects because they often connect CRMs, email tools, ad platforms, analytics, webhooks, and CLIs.

Next step: inventory required environment variables without revealing values.

Secret Inventory

VariableServiceEnvironmentRequiredScopeOwnerRotation CadenceNotes

Classify each variable.

TypeExamplesHandling
Public configPublic API base URL, analytics public keyCan appear in client when intended
Server secretAPI key, private token, webhook secretServer only
Build secretPackage token, deploy tokenCI or deploy platform only
Local secretDeveloper sandbox keyLocal .env, never committed
Rotating credentialOAuth refresh token, signing secretStore in managed secret system

Next step: separate public config from true secrets.

File Strategy

Recommended files:

.env.example
.env.local
.env.development
.env.test
.env.production

Rules:

  • Commit .env.example with variable names and safe placeholder values.
  • Do not commit real .env files.
  • Add .env* to .gitignore, except .env.example if the project needs it.
  • Keep production secrets in the deployment platform or managed secrets store.
  • Use different keys for development, staging, and production.

Next step: create or update .env.example without real values.

Rotation Workflow

  1. Identify affected service.
  2. Revoke or rotate the exposed credential.
  3. Update local, CI, staging, and production secret stores.
  4. Restart dependent services.
  5. Verify functionality.
  6. Search recent commits and logs for exposed values.
  7. Document the incident and prevention step.

Do not paste the exposed secret into tickets, chat, commits, or documentation.

Next step: rotate the highest-risk exposed key first.

Common Marketing Stack Variables

Service TypeExample Variables
CRMHUBSPOT_ACCESS_TOKEN, SALESFORCE_CLIENT_SECRET
EmailMAILCHIMP_API_KEY, SENDGRID_API_KEY
AnalyticsGA4_PROPERTY_ID, POSTHOG_PROJECT_API_KEY
AdsMETA_ACCESS_TOKEN, GOOGLE_ADS_DEVELOPER_TOKEN
WebhooksWEBHOOK_SIGNING_SECRET, STRIPE_WEBHOOK_SECRET
GitHubGITHUB_TOKEN
AIOPENAI_API_KEY, ANTHROPIC_API_KEY

Next step: map each variable to the tool or CLI that needs it.

Output Format

PrioritySecret AreaRiskFixOwnerVerification

Then provide current risk summary, .env.example plan, rotation plan, deployment checklist, CI checklist, and local developer setup instructions.

End with the safest next action to reduce credential risk.

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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