STRIPE_SECRET_KEY = "..." under [vars] ships your key in plain text with every deploy and shows it in the dashboard, and a KV preview_id that equals its id means every wrangler dev --remote session writes to your production data. This skill finds those and eight other Wrangler config mistakes before you deploy, and tells you how to fix each one.

Your agent runs a scanner on your project: wrangler.toml, wrangler.json and wrangler.jsonc (also named variants such as wrangler.staging.toml, in every subfolder of a monorepo), for Workers and Pages, plus the .dev.vars and .env files next to them. It parses TOML and JSON with comments and trailing commas with a line number for every key, and follows Wrangler's own rules: [env.NAME] sections, inherited keys such as routes and workers_dev, bindings that are not inherited, the Pages production and preview environments and the previews block. It reads .gitignore to tell whether local secret files are left out of git. It never runs Wrangler, deploys or calls the Cloudflare API. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• W01: passwords, tokens, keys and database URLs with passwords in vars (top level, environments and previews)

• W02: a KV preview_id, D1 preview_database_id or R2 preview_bucket_name equal to the production one

• W03: secrets in define, a Hyperdrive localConnectionString for a remote database, URLs with user:password@, and known token formats anywhere in the file

REVIEW (check before release)

• W11: a compatibility_date more than a year old

• W12: workers_dev = true or preview_urls = true on a Worker that serves your own routes

• W13: a Worker with routes, or a Pages project, that binds KV, D1, R2 or Hyperdrive with no staging or preview environment

• W14: staging, preview and development environments bound to the same KV namespace, D1 database, R2 bucket, Hyperdrive config, queue or service as production

• W15: removed or unused settings: node_compat, legacy_assets, site, usage_model, type, webpack_config, build.upload

• W16: assets.directory, site.bucket or pages_build_output_dir set to the project folder itself

• W17: .dev.vars and .env files with values that no .gitignore rule covers

What's included

• The scanner (Python 3.9+, standard library only)

• A rules guide with the reason and safer approach for each rule

• A risky and a safe example project (a Worker API and a Pages site), and the real report the scanner produces on the risky one

Limits

It reads the config files as written. Secrets and settings made in the Cloudflare dashboard or with wrangler secret put, command-line flags such as --var and --env, config generated by build tools, your Worker's code, and the contents of your KV, D1 and R2 resources are not checked. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 20 files: SKILL.md, the scanner in scripts/ (5 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (12 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.