Skip to main content
hc
Submit
agentsSource-backedReview first Safety ✓ Privacy ✓

Cloudflare Workers Deployment Review Agent

Source-backed agent for reviewing Cloudflare Workers deployments before production release, covering wrangler config, bindings, routes, secrets, compatibility flags, and rollback plans aligned to official Cloudflare docs.

by kiannidev·added 2026-06-15·
Claude Code
HarnessClaude Code
Review first — review before installing

Open the source and read safety notes before installing.

Safety notes

  • Workers deployments can change live traffic immediately; treat production deploy review as release-impacting work requiring explicit approval.
  • Do not run production deploy commands from unreviewed forks or unverified CI workflows with Cloudflare API tokens.
  • Bindings to production KV, R2, D1, or Queues can cause data loss or cross- environment contamination if environment names are wrong.
  • Wrangler rollback and versions features reduce but do not eliminate blast radius; verify rollback steps before deploy.

Privacy notes

  • Wrangler configs, Worker logs, and binding metadata can expose account IDs, internal hostnames, customer routes, and secret names.
  • Workers observability logs may contain request payloads, auth headers, and user identifiers; redact before sharing review notes externally.
  • API tokens and OAuth client secrets must not appear in prompts, PR comments, or generated review output.
  • Third-party observability exports remain subject to vendor retention policies separate from Cloudflare account settings.

Prerequisites

  • Worker source repository with wrangler config, routes, and environment definitions for staging and production.
  • Cloudflare account access to inspect bindings (KV, R2, D1, Queues, AI, etc.), routes, and deployment history.
  • CI or local Wrangler deploy command output from a staging dry run when available.
  • Maintainer approval path before production deploy or traffic shift.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Full copyable content
## Content

Cloudflare Workers Deployment Review Agent is a reusable agent prompt for
reviewing Worker deployments before they reach production traffic. It focuses on
Wrangler configuration correctness, binding targets, route coverage, secret
handling, compatibility flags, observability readiness, and rollback plans.

Use this agent before `wrangler deploy`, promoting a versions deployment, or
merging infrastructure PRs that change routes, bindings, or environment names.

## Agent Prompt

You are a Cloudflare Workers deployment reviewer. Use official Cloudflare Workers,
Wrangler, bindings, and observability documentation plus the public `workers-sdk`
repository as evidence. Review staging behavior before recommending production deploy.

Review workflow:

1. Config. Inspect wrangler.toml/json, environment names, compatibility_date/flags,
   and build commands for staging vs production parity.
2. Bindings. Verify KV, R2, D1, Queues, AI, and service bindings point to intended
   resources—not staging assets in production slots.
3. Routes and triggers. Confirm routes, custom domains, cron triggers, and queue
   consumers match the intended traffic scope.
4. Secrets and vars. Check secret names, non-secret vars, and absence of credentials
   in repo files or CI logs.
5. Deploy mechanics. Review deploy command, versions upload, gradual rollout, and
   documented rollback via Wrangler versions or previous deployment IDs.
6. Observability. Ensure Workers logs, traces, or analytics will surface regressions
   with actionable dashboards or alerts.
7. Decision. Approve staging deploy, block production promote, or request fixes with
   explicit owners.

Output contract:

- Environment and config summary.
- Binding and route findings with severity.
- Secret and compatibility review notes.
- Rollback plan with triggers.
- Deploy decision and follow-up tasks.

## Features

- Reviews Wrangler config and environment separation.
- Validates bindings, routes, triggers, and secrets before deploy.
- Checks compatibility flags and build parity across environments.
- Produces rollback plans tied to Wrangler versions behavior.

## Use Cases

- Pre-flight review before production Worker deploys.
- Audit infrastructure PRs that add D1, KV, R2, or Queue bindings.
- Validate cron or queue consumer deployments with blast-radius notes.
- Handoff review between staging promotion and customer-facing release.

## Source Notes

- Cloudflare documents Wrangler deploy commands, configuration files, environments,
  and bindings with explicit warnings about production impact.
- Workers observability docs describe logs and tracing surfaces useful for post-deploy
  verification.
- The public `workers-sdk` repository provides Wrangler behavior references for
  deploy, versions, and rollback commands.

## Duplicate Check

Checked `content/agents/`, `content/skills/`, open PRs, and the live catalog.
Skills such as `wrangler-deployment-operations-capability-pack` and
`cloudflare-workers-d1-kv-r2-capability-pack` cover operational patterns, and
`cloudflare-deploy-readiness` is a slash command. No `agents` entry provides a
Workers deployment review agent prompt with binding/route/rollback output contract.

## Editorial Disclosure

Submitted as an independent community agent entry by `kiannidev`, based on public
Cloudflare Workers documentation and the public `cloudflare/workers-sdk` repository.
No paid placement, referral, or affiliate relationship.

## Sources

- Wrangler deploy commands: https://developers.cloudflare.com/workers/wrangler/commands/#deploy
- Workers configuration: https://developers.cloudflare.com/workers/wrangler/configuration/
- Workers bindings: https://developers.cloudflare.com/workers/runtime-apis/bindings/
- Workers logs: https://developers.cloudflare.com/workers/observability/logs/workers-logs/
- workers-sdk repository: https://github.com/cloudflare/workers-sdk

About this resource

Content

Cloudflare Workers Deployment Review Agent is a reusable agent prompt for reviewing Worker deployments before they reach production traffic. It focuses on Wrangler configuration correctness, binding targets, route coverage, secret handling, compatibility flags, observability readiness, and rollback plans.

Use this agent before wrangler deploy, promoting a versions deployment, or merging infrastructure PRs that change routes, bindings, or environment names.

Agent Prompt

You are a Cloudflare Workers deployment reviewer. Use official Cloudflare Workers, Wrangler, bindings, and observability documentation plus the public workers-sdk repository as evidence. Review staging behavior before recommending production deploy.

Review workflow:

  1. Config. Inspect wrangler.toml/json, environment names, compatibility_date/flags, and build commands for staging vs production parity.
  2. Bindings. Verify KV, R2, D1, Queues, AI, and service bindings point to intended resources—not staging assets in production slots.
  3. Routes and triggers. Confirm routes, custom domains, cron triggers, and queue consumers match the intended traffic scope.
  4. Secrets and vars. Check secret names, non-secret vars, and absence of credentials in repo files or CI logs.
  5. Deploy mechanics. Review deploy command, versions upload, gradual rollout, and documented rollback via Wrangler versions or previous deployment IDs.
  6. Observability. Ensure Workers logs, traces, or analytics will surface regressions with actionable dashboards or alerts.
  7. Decision. Approve staging deploy, block production promote, or request fixes with explicit owners.

Output contract:

  • Environment and config summary.
  • Binding and route findings with severity.
  • Secret and compatibility review notes.
  • Rollback plan with triggers.
  • Deploy decision and follow-up tasks.

Features

  • Reviews Wrangler config and environment separation.
  • Validates bindings, routes, triggers, and secrets before deploy.
  • Checks compatibility flags and build parity across environments.
  • Produces rollback plans tied to Wrangler versions behavior.

Use Cases

  • Pre-flight review before production Worker deploys.
  • Audit infrastructure PRs that add D1, KV, R2, or Queue bindings.
  • Validate cron or queue consumer deployments with blast-radius notes.
  • Handoff review between staging promotion and customer-facing release.

Source Notes

  • Cloudflare documents Wrangler deploy commands, configuration files, environments, and bindings with explicit warnings about production impact.
  • Workers observability docs describe logs and tracing surfaces useful for post-deploy verification.
  • The public workers-sdk repository provides Wrangler behavior references for deploy, versions, and rollback commands.

Duplicate Check

Checked content/agents/, content/skills/, open PRs, and the live catalog. Skills such as wrangler-deployment-operations-capability-pack and cloudflare-workers-d1-kv-r2-capability-pack cover operational patterns, and cloudflare-deploy-readiness is a slash command. No agents entry provides a Workers deployment review agent prompt with binding/route/rollback output contract.

Editorial Disclosure

Submitted as an independent community agent entry by kiannidev, based on public Cloudflare Workers documentation and the public cloudflare/workers-sdk repository. No paid placement, referral, or affiliate relationship.

Sources

#cloudflare#workers#wrangler#deployment#devops

Source citations

Add this badge to your README

Show that Cloudflare Workers Deployment Review Agent is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/agents/cloudflare-workers-deployment-review-agent.svg)](https://heyclau.de/entry/agents/cloudflare-workers-deployment-review-agent)

How it compares

Cloudflare Workers Deployment Review Agent side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

FieldCloudflare Workers Deployment Review Agent

Source-backed agent for reviewing Cloudflare Workers deployments before production release, covering wrangler config, bindings, routes, secrets, compatibility flags, and rollback plans aligned to official Cloudflare docs.

Open dossier 		/deploy-readiness - Cloudflare Deploy Readiness Command for Claude Code

Slash command that runs a pre-deploy readiness check for a Cloudflare Workers project before you ship.

Open dossier 		Cloudflare Wrangler Config Guard Hook for Claude Code

Read-only Claude Code PostToolUse hook that checks edited Cloudflare Wrangler config files for required Worker fields, environment inheritance traps, secret-like vars, deprecated Workers Sites usage, and source-of-truth drift before Claude continues.

Open dossier 		Wrangler Deployment Operations Capability Pack Skill

Expert Wrangler CLI deployment skill for release planning, config review, environment checks, version traffic splits, trigger application, and rollback.

Open dossier
Trust
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
Categoryagentscommandshooksskills
Sourcesource-backedsource-backedsource-backedsource-backed
Authorkiannidevjony376oktofeesh1oktofeesh1
Added2026-06-152026-06-042026-06-042026-06-03
Platforms
Claude Code
Claude Code
Claude Code
Claude CodeCodexWindsurfGeminiCursorCLI
Source repo————
Safety notes✓Workers deployments can change live traffic immediately; treat production deploy review as release-impacting work requiring explicit approval. Do not run production deploy commands from unreviewed forks or unverified CI workflows with Cloudflare API tokens. Bindings to production KV, R2, D1, or Queues can cause data loss or cross- environment contamination if environment names are wrong. Wrangler rollback and versions features reduce but do not eliminate blast radius; verify rollback steps before deploy.✓Runs Wrangler auth, secret-list, and deploy dry-run checks, but Wrangler deploy --dry-run still executes the project's local build/bundling pipeline and any configured build command or plugins. Run this command only in a trusted Workers repository after reviewing wrangler config, package scripts, and bundler plugins; do not use it to evaluate untrusted submissions. Never run a real deploy or publish, and validate any environment argument before passing it to Wrangler.✓This hook is static and read-only. It reads only non-symlinked Wrangler config files inside the current project and does not run `wrangler deploy`, `wrangler dev`, `wrangler whoami`, `wrangler secret list`, package scripts, build plugins, or network commands. The hook exits non-zero only for parse failures or missing required top-level Worker fields such as `name` and `compatibility_date`; warnings remain advisory so the user can review them. The TOML checks are heuristic and do not replace Wrangler's own parser or a trusted pre-deploy dry run. Use them as a fast edit-time guard, then run official Wrangler validation in a trusted repository. Do not expand this hook into a dry-run deploy hook unless the team has reviewed local build-script execution, inherited environment variables, and output-directory cleanup. Keep matchers scoped to config file edits. Running config checks after every tool call adds noise without improving Cloudflare safety.✓Wrangler deployment and rollback commands mutate live Worker traffic; verify account, Worker name, route, and environment before running them. The archive URL points to Cloudflare's external Workers SDK tag archive; pin versions and review release provenance before using it in CI. Use least-privilege API tokens and secret stores; never commit `.dev.vars`, `.env`, tokens, account credentials, or CI secret values. Version rollback can restore Worker code/config traffic but does not restore bound KV, R2, D1, Durable Object, queue, or downstream service state. Trigger and route updates can change public reachability; treat them as separate release steps with explicit verification.
Privacy notes✓Wrangler configs, Worker logs, and binding metadata can expose account IDs, internal hostnames, customer routes, and secret names. Workers observability logs may contain request payloads, auth headers, and user identifiers; redact before sharing review notes externally. API tokens and OAuth client secrets must not appear in prompts, PR comments, or generated review output. Third-party observability exports remain subject to vendor retention policies separate from Cloudflare account settings.✓Wrangler output entering the model context can include your account id, worker name, environment name, and secret names (never secret values). The dry-run build reads source files and may execute project-controlled local code with inherited environment variables, including Cloudflare-related tokens; review the project before running on sensitive accounts. The command writes Wrangler dry-run output to disk and project build tooling may write additional local files.✓The hook reads `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` only inside the current project, with symlinks rejected and a 1 MiB size cap. Wrangler config files can contain worker names, route patterns, account identifiers, resource IDs, binding names, environment names, analytics settings, and non-secret vars. Hook output may include file paths, config key names, environment names, and secret-like variable names, so avoid pasting terminal logs into public issue comments without review. If a Wrangler config currently contains real secrets in `vars`, the hook can reveal the key names and the surrounding configuration context. Move sensitive values to Wrangler secrets before sharing output.✓Wrangler deploy uploads bundled Worker source, static assets, and configuration metadata to the target account. Release logs can include request URLs, headers, exception details, route names, account IDs, and zone IDs; redact before sharing publicly. CI deploys rely on API tokens and account IDs; avoid printing environment dumps, secret values, or full request payloads in logs. Worker routes, custom domains, and account metadata can reveal infrastructure topology; keep public notes minimal and intentional.
Prerequisites
  • Worker source repository with wrangler config, routes, and environment definitions for staging and production.
  • Cloudflare account access to inspect bindings (KV, R2, D1, Queues, AI, etc.), routes, and deployment history.
  • CI or local Wrangler deploy command output from a staging dry run when available.
  • Maintainer approval path before production deploy or traffic shift.
— none listed
  • Claude Code project where hooks are allowed by user or project policy.
  • Cloudflare Workers or Pages project with `wrangler.toml`, `wrangler.json`, or `wrangler.jsonc` checked into the repository.
  • `jq` available locally to parse Claude Code hook input.
  • Node.js available locally for static JSON/JSONC/TOML heuristics.
  • Wrangler-managed Worker project or release plan
  • Project-local Node.js toolchain that satisfies the pinned Wrangler package engines
  • Access to account ID, Worker name, environment name, route, and binding inventory
  • CI or local authentication plan for non-interactive deploys
Install—
/deploy-readiness
mkdir -p .claude/hooks && touch .claude/hooks/wrangler-config-guard.sh && chmod +x .claude/hooks/wrangler-config-guard.sh
npm install --save-dev wrangler@4.97.0 && npx wrangler --version
Config——
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "./.claude/hooks/wrangler-config-guard.sh"
          }
        ]
      }
    ]
  }
}
—
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.