菜单
Use this skill when a task involves adding, removing, or renaming environment variables across the project's repos OR verifying env var documentation before a release. Don't use it for runtime env introspection in a live cluster (that requires exec access to the running service).
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/atretyak1985/swarmery --skill env-check命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | env-check |
| version | 1.0.0 |
| owner | swarmery-core |
| description | Use this skill when a task involves adding, removing, or renaming environment variables across the project's repos OR verifying env var documentation before a release. Don't use it for runtime env introspection in a live cluster (that requires exec access to the running service). |
| disable-model-invocation | true |
| allowed-tools | Read, Grep, Glob |
| color | teal |
| docs | {"status":"reviewed","source_sha":"1cd8c6fbf3fd","updated":"2026-08-06T00:00:00.000Z"} |
Audit environment variables across all of the project's repositories (see .claude/project.json → repos) to find missing, unused, undocumented, or inconsistent env vars and flag security issues. Produce a structured markdown report with file:line citations. Related skills: gcp-cicd-auth (for cloud credential variables), deployment (for CI/CD variable plumbing and runtime values injection).
env.examplevalues.yaml, env.example, getServerEnv(), or clientEnvgcp-cicd-auth.claude/project.json → repos, plus the device/edge repo (device) if the project has one. Typical shape: the main app, other apps, the infrastructure repo, and the device repo.repos: string[] -- list of repository root paths to audit (default: the project's full repo list above)focus: string (optional) -- specific env var name or prefix to audit (e.g., NEXT_PUBLIC_, MOCK_MODE)Format: Markdown report saved to the path specified by the caller.
Length budget: Max 150 lines for the report body. Consolidate tables with more than 20 rows into a top-20 list sorted by severity, with a count of omitted items.
Output template:
N
N
N
N
HIGH | MEDIUM (if dynamic env access patterns detected)
| Repo | Defined | Used | Documented | Issues |
|------|---------|------|------------|--------|
| apps/ | 12 | 14 | 10 | 4 |
| Variable | Used at | Expected in |
|----------|---------|-------------|
| | | |
| Variable | Declared in | Last referenced |
|----------|-------------|-----------------|
| | | nowhere |
| Issue | Location | Severity |
|-------|----------|----------|
| Hardcoded API key | | critical |
[Dynamic env access patterns that could not be resolved statically]
Glob for env-related files -- Use patterns **/.env*, **/env.example, **/values*.yaml, **/*.populated.yaml, **/env/server.ts, **/env/client.ts.
Glob operations across different repos are independent -- run all repo scans as parallel tool calls.
Checkpoint: at least one env file found per repo.
Grep for env var usage per repo (run all repo greps in parallel):
os.environ.get(, os.getenv( in src/process.env. in src/, NEXT_PUBLIC_ in src/ (incl. access via getServerEnv() / clientEnv helpers)env: sections and {{ .Values.* }} references in templates/, keys in values.yamlnode_modules/, .next/, __pycache__/, venv/
Checkpoint: count of unique var names per repo.Cross-reference -- Compare defined vars vs used vars vs documented vars. Documentation sources: env.example, plus README.md / CLAUDE.md / setup guides mentions. Flag: (a) used but not in env.example, (b) in env.example but never used, (c) inconsistent naming across repos for the same logical var.
Checkpoint: cross-reference table populated.
Security check -- Flag hardcoded strings that look like secrets (API keys, passwords, tokens) in source code. Verify sensitive vars use the runtime's secret manager (not committed values.yaml). Verify *.populated.yaml files are in .gitignore. NEVER print actual secret values in the report -- only flag presence and file:line location.
Checkpoint: security findings logged.
Detect dynamic access -- Grep for process.env[ (bracket notation) and os.environ[ patterns. Mark these as low-confidence findings since the var name cannot be resolved statically.
Checkpoint: dynamic access patterns counted.
Compile report -- Assemble findings into the output template above. Every finding must include file:line citation. Respect the 150-line length budget.
Checkpoint: report complete, all sections present.
Build the expectation set from the project itself -- the env.example files in each repo, the project's CLAUDE.md, and any setup guides. Typical shapes to expect (always verify against current code, never assume exhaustive):
NEXT_PUBLIC_* client keys, DATABASE_URL, auth provider vars (NEXTAUTH_* / AUTH_*), cache/queue URLsimage.tag, ingress settings, DNS suffixesfile:line citationnode_modules/, .next/, __pycache__/, test fixtures excluded from scannode_modules/, .next/, or other generated directories -- they contain false positivesprocess.env[dynamicKey] as a specific missing var -- flag as low-confidence dynamic accessNEXT_PUBLIC_* vars are server-side -- they are client-exposed and have different security implicationsvalues.yaml*.populated.yaml files that are NOT in .gitignore*.populated.yaml file containing apparent secrets is NOT in .gitignore (potential secret leak)Task: Verify BACKEND_API_URL is consistent across the device/edge repo and the service config in the infrastructure repo.
Step 1 -- Grep the device/edge repo:
Grep: os.environ.get("BACKEND_API_URL" in <device>/src/
Found: src/agents/main_agent.py:12 BACKEND_API_URL = os.environ.get("BACKEND_API_URL", "http://localhost:3000")
Step 2 -- Grep the service config (run in parallel with Step 1):
Grep: BACKEND_API_URL in the infrastructure repo
Found: charts/<device>/values.yaml:18 BACKEND_API_URL: "http://<mainApp>:3000"
Found: charts/<device>/templates/deployment.yaml:42 - name: BACKEND_API_URL
Step 3 -- Cross-reference:
http://localhost:3000http://<mainApp>:3000Step 4 -- Check env.example:
Grep: BACKEND_API_URL in <device>/env.example
Not found -- MISSING from env.example
Report entry:
| `BACKEND_API_URL` | `src/agents/main_agent.py:12` | `env.example` |
.next/ or node_modules/ -> detect: finding count >50 for a single repo -> fix: verify exclusion patterns are applied, re-run scanprocess.env[ bracket patterns -> fix: grep for bracket notation, add to low-confidence sectionsk-, AIza, base64 strings -> fix: immediately delete the report, re-run with value-scrubbing check, notify usergcp-cicd-auth -- defer to this skill for GCP-specific credential variables and Workload Identity Federation setupdeployment -- compose with this skill when CI/CD pipeline variables need to match application env varsdeployment -- compose with this skill when verifying that Cloud Run values match application expectationsdeps-check -- shares the same canonical five-repo scope; align repo lists when auditing both env vars and dependenciesThis skill audits environment variables across every repository in your project. It reads code, config, and example files without writing anything, then reports which variables are used but undocumented, documented but unused, named inconsistently across repos, or look like hardcoded secrets. Every finding comes with a file:line citation so you can go straight to the line that matters.
env.example.env.example, or a typed env accessor.gcp-cicd-auth skill.deployment skill.deps-check skill.Skill(skill: "core:env-check")
Invoke it directly, or ask in plain language ("check env vars across the repos") and the skill activates on its own.
repos — list of repository root paths to audit — optional; defaults to the project's full repo list from .claude/project.json → repos.focus — a single variable name or a prefix such as NEXT_PUBLIC_ — optional; narrows the audit to matching variables.A markdown report, capped at 150 lines, with a summary header (repos checked, variables found, documented, missing, confidence level) followed by tables: per-repo counts, missing variables, unused variables, security issues, and any dynamic access patterns the scan could not resolve statically. Secret values are never printed — only the location where one appears. The skill stops and asks you first if it finds an apparent secret file outside .gitignore, more than five undocumented variables, or heavy dynamic access that makes the result unreliable.
Skill(skill: "core:env-check")
Focus: BACKEND_API_URL
Greps the device repo and the infrastructure repo in parallel:
src/agents/main_agent.py:12 default "http://localhost:3000"
charts/<device>/values.yaml:18 "http://<mainApp>:3000"
Cross-references env.example: not found.
Report entry:
| `BACKEND_API_URL` | `src/agents/main_agent.py:12` | `env.example` |
The naming is consistent and the differing defaults are expected (local dev vs in-cluster DNS), so the one real finding is the missing env.example entry.
deps-check — same repo scope, but for package versions instead of variables.deployment — pair with it when pipeline variables must match what the application expects.gcp-cicd-auth — use it for cloud credential variables and federated identity setup.security-audit — broader vulnerability sweep when secrets are only part of the concern.