agentleFS
Sign inStart free
daizhouchendaizhouchen/openclaw-skills/skills/env-guardian/SKILL.md

env-guardian

Skill0 starsChanged 48 days agoMITView on GitHub

审计项目环境变量的引用、缺失配置和潜在泄露，并按需生成 .env.example。用于环境变量或配置安全检查，不扩展为一般项目配置审计。

  • Reads credentials

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the scanner to discover all environment variable references across the project:

    line 17
  2. Distinctive:

    Run the security checker:

    line 33
  3. Distinctive:

    CRITICAL: Never display actual secret values in output.

    line 45
  4. Distinctive:

    If the user wants to fix or improve their setup, run:

    line 51
  5. Distinctive:

    NEVER output actual secret values.

    line 74
  6. Very specific:

    If .env is not in .gitignore, flag this as CRITICAL.

    line 75
  7. Distinctive:

    If credentials are found in Git history, recommend revocation or rotation first.

    line 76
  8. Distinctive:

    Keep the audit focused on environment variables.

    line 78

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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-guardian: Environment Variable Guardian

Resolve <skill_dir> to the directory containing this SKILL.md. Use absolute helper paths, keep project/output paths separate, and generate only the outputs needed for the user's request.

You are the env-guardian skill. Your job is to scan projects for environment variable usage and check security, completeness, and consistency.

Workflow

Step 1: Scan Environment Variables

Run the scanner to discover all environment variable references across the project:

python3 "<skill_dir>/scripts/scan_env.py" TARGET_PROJECT_DIR

This scans Python, JavaScript, Ruby, Go, Docker, and CI/CD files for env var references, and parses all .env* files.

Review the JSON output. Summarize:

  • Total unique env vars found
  • Which languages/frameworks reference them
  • Any vars referenced in code but missing from .env or .env.example
  • Any vars defined in .env but never referenced in code

Step 2: Security Check

Run the security checker:

python3 "<skill_dir>/scripts/check_security.py" TARGET_PROJECT_DIR

This checks:

  • Whether .env is listed in .gitignore
  • Whether .env was ever committed to git history
  • Hardcoded secrets in source code (patterns like KEY=xxx, PASSWORD=xxx, etc.)
  • Sensitive variable names without proper handling

CRITICAL: Never display actual secret values in output. The script redacts them automatically.

Report all findings with severity levels (CRITICAL, WARNING, INFO).

Step 3: Generate .env.example and Config Loader

If the user wants to fix or improve their setup, run:

python3 "<skill_dir>/scripts/generate_env_example.py" TARGET_PROJECT_DIR

This generates:

  • A comprehensive .env.example with categorized variables, comments, and placeholder values
  • A type-safe Python config loader class

Present the generated files to the user for review before writing them.

Step 4: Report Summary

Present a clear summary to the user:

  1. Environment Variable Inventory - table of all discovered vars, where they are used, and whether they are defined
  2. Security Findings - any issues found, ordered by severity
  3. Recommendations - concrete steps to fix any problems
  4. Generated Files - offer to create .env.example and config loader if needed

Important Rules

  • NEVER output actual secret values. Always redact.
  • If .env is not in .gitignore, flag this as CRITICAL.
  • If credentials are found in Git history, recommend revocation or rotation first. History rewriting is a separate, coordinated task; do not run it as part of an audit.
  • Group env vars by category (database, API keys, app config, auth, etc.) in reports.
  • Keep the audit focused on environment variables. Write fixes only when included in the request.

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