Your knowledge of Cloudflare Workers APIs, types, and configuration may be outdated. Prefer retrieval over pre-training for any Workers code task — writing or reviewing.
Retrieval Sources
Fetch the latest versions before writing or reviewing Workers code. Do not rely on baked-in knowledge for API signatures, config fields, or binding shapes.
| Source |
How to retrieve |
Use for |
| Workers best practices |
Fetch https://developers.cloudflare.com/workers/best-practices/workers-best-practices/ |
Canonical rules, patterns, anti-patterns |
| Workers types |
See references/review.md for retrieval steps |
API signatures, handler types, binding types |
| Wrangler config schema |
node_modules/wrangler/config-schema.json |
Config fields, binding shapes, allowed values |
| Cloudflare docs |
Search tool or https://developers.cloudflare.com/workers/ |
API reference, compatibility dates/flags |
FIRST: Fetch Latest References
Before reviewing or writing Workers code, retrieve the current best-practices page when web access is available. Validate code against the project's installed Wrangler and Workers types because those determine what the project can compile and deploy. Consult the latest published types only to discuss a deliberate upgrade.
# Inspect the installed types and Wrangler schema
rg --files node_modules/@cloudflare/workers-types node_modules/wrangler 2>/dev/null
Reference Documentation
references/rules.md — all best practice rules with code examples and anti-patternsreferences/review.md — type validation, config validation, binding access patterns, review process
Rules Quick Reference
Configuration
| Rule |
Summary |
| Compatibility date |
Set compatibility_date to today on new projects; update periodically on existing ones |
| nodejs_compat |
Enable the nodejs_compat flag — many libraries depend on Node.js built-ins |
| wrangler types |
Run wrangler types to generate Env — never hand-write binding interfaces |
| Secrets |
Use wrangler secret put, never hardcode secrets in config or source |
| wrangler.jsonc |
Use JSONC config for non-secret settings — newer features are JSON-only |
Request & Response Handling
| Rule |
Summary |
| Streaming |
Stream large/unknown payloads — never await response.text() on unbounded data |
| waitUntil |
Use ctx.waitUntil() for post-response work; do not destructure ctx |
Architecture
| Rule |
Summary |
| Bindings over REST |
Use in-process bindings (KV, R2, D1, Queues) — not the Cloudflare REST API |
| Queues & Workflows |
Move async/background work off the critical path |
| Service bindings |
Use service bindings for Worker-to-Worker calls — not public HTTP |
| Hyperdrive |
Always use Hyperdrive for external PostgreSQL/MySQL connections |
Observability
| Rule |
Summary |
| Logs & Traces |
Enable observability in config with head_sampling_rate; use structured JSON logging |
Code Patterns
| Rule |
Summary |
| No global request state |
Never store request-scoped data in module-level variables |
| Floating promises |
Await or return required work; use ctx.waitUntil() for background work. void alone neither handles rejection nor extends lifetime |
Security
| Rule |
Summary |
| Web Crypto |
Use crypto.randomUUID() / crypto.getRandomValues() — never Math.random() for security |
| No passThroughOnException |
Use explicit try/catch with structured error responses |
Anti-Patterns to Flag
| Anti-pattern |
Why it matters |
await response.text() on unbounded data |
Memory exhaustion — 128 MB limit |
| Hardcoded secrets in source or config |
Credential leak via version control |
Math.random() for tokens/IDs |
Predictable, not cryptographically secure |
Bare fetch() without await or waitUntil |
Floating promise — dropped result, swallowed error |
| Module-level mutable variables for request state |
Cross-request data leaks, stale state, I/O errors |
| Cloudflare REST API from inside a Worker |
Unnecessary network hop, auth overhead, added latency |
ctx.passThroughOnException() as error handling |
Hides bugs, makes debugging impossible |
Hand-written Env interface |
Drifts from actual wrangler config bindings |
| Direct string comparison for secret values |
Timing side-channel — use crypto.subtle.timingSafeEqual |
Destructuring ctx (const { waitUntil } = ctx) |
Loses this binding — throws "Illegal invocation" at runtime |
any on Env or handler params |
Defeats type safety for all binding access |
as unknown as T double-cast |
Hides real type incompatibilities — fix the design |
implements on platform base classes (instead of extends) |
Legacy — loses this.ctx, this.env. Applies to DurableObject, WorkerEntrypoint, Workflow |
env.X without a scoped env variable in a platform class |
Use this.env.X; a constructor or method parameter named env is valid |
Review Workflow
- Retrieve — fetch latest best practices page, workers types, and wrangler schema
- Read full files — not just diffs; context matters for binding access patterns
- Check types — binding access, handler signatures, no
any, no unsafe casts (see references/review.md)
- Check config — compatibility_date, nodejs_compat, observability, secrets, binding-code consistency
- Check patterns — streaming, floating promises, global state, serialization boundaries
- Check security — crypto usage, secret handling, timing-safe comparisons, error handling
- Validate with project tools — use the repository's installed typecheck and lint scripts; do not download a floating tool version for review
- Reference rules — see
references/rules.md for each rule's correct pattern
Scope
This skill covers Workers-specific best practices and code review. For related topics:
- Durable Objects: load the
durable-objects skill
- Workflows: see Rules of Workflows
- Wrangler CLI commands: load the
wrangler skill
Principles
- Be certain. Retrieve before flagging. If unsure about an API, config field, or pattern, fetch the docs first.
- Provide evidence. Reference line numbers, tool output, or docs links.
- Focus on what developers will copy. Workers code in examples and docs gets pasted into production.
- Correctness over completeness. A concise example that works beats a comprehensive one with errors.
1---2name: workers-best-practices3description: Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.4---56Your knowledge of Cloudflare Workers APIs, types, and configuration may be outdated. **Prefer retrieval over pre-training** for any Workers code task — writing or reviewing.78## Retrieval Sources910Fetch the **latest** versions before writing or reviewing Workers code. Do not rely on baked-in knowledge for API signatures, config fields, or binding shapes.1112| Source | How to retrieve | Use for |13|--------|----------------|---------|14| Workers best practices | Fetch `https://developers.cloudflare.com/workers/best-practices/workers-best-practices/` | Canonical rules, patterns, anti-patterns |15| Workers types | See `references/review.md` for retrieval steps | API signatures, handler types, binding types |16| Wrangler config schema | `node_modules/wrangler/config-schema.json` | Config fields, binding shapes, allowed values |17| Cloudflare docs | Search tool or `https://developers.cloudflare.com/workers/` | API reference, compatibility dates/flags |1819## FIRST: Fetch Latest References2021Before reviewing or writing Workers code, retrieve the current best-practices page when web access is available. Validate code against the project's installed Wrangler and Workers types because those determine what the project can compile and deploy. Consult the latest published types only to discuss a deliberate upgrade.2223```bash24# Inspect the installed types and Wrangler schema25rg --files node_modules/@cloudflare/workers-types node_modules/wrangler 2>/dev/null26```2728## Reference Documentation2930- `references/rules.md` — all best practice rules with code examples and anti-patterns31- `references/review.md` — type validation, config validation, binding access patterns, review process3233## Rules Quick Reference3435### Configuration3637| Rule | Summary |38|------|---------|39| Compatibility date | Set `compatibility_date` to today on new projects; update periodically on existing ones |40| nodejs_compat | Enable the `nodejs_compat` flag — many libraries depend on Node.js built-ins |41| wrangler types | Run `wrangler types` to generate `Env` — never hand-write binding interfaces |42| Secrets | Use `wrangler secret put`, never hardcode secrets in config or source |43| wrangler.jsonc | Use JSONC config for non-secret settings — newer features are JSON-only |4445### Request & Response Handling4647| Rule | Summary |48|------|---------|49| Streaming | Stream large/unknown payloads — never `await response.text()` on unbounded data |50| waitUntil | Use `ctx.waitUntil()` for post-response work; do not destructure `ctx` |5152### Architecture5354| Rule | Summary |55|------|---------|56| Bindings over REST | Use in-process bindings (KV, R2, D1, Queues) — not the Cloudflare REST API |57| Queues & Workflows | Move async/background work off the critical path |58| Service bindings | Use service bindings for Worker-to-Worker calls — not public HTTP |59| Hyperdrive | Always use Hyperdrive for external PostgreSQL/MySQL connections |6061### Observability6263| Rule | Summary |64|------|---------|65| Logs & Traces | Enable `observability` in config with `head_sampling_rate`; use structured JSON logging |6667### Code Patterns6869| Rule | Summary |70|------|---------|71| No global request state | Never store request-scoped data in module-level variables |72| Floating promises | Await or return required work; use `ctx.waitUntil()` for background work. `void` alone neither handles rejection nor extends lifetime |7374### Security7576| Rule | Summary |77|------|---------|78| Web Crypto | Use `crypto.randomUUID()` / `crypto.getRandomValues()` — never `Math.random()` for security |79| No passThroughOnException | Use explicit try/catch with structured error responses |8081## Anti-Patterns to Flag8283| Anti-pattern | Why it matters |84|-------------|----------------|85| `await response.text()` on unbounded data | Memory exhaustion — 128 MB limit |86| Hardcoded secrets in source or config | Credential leak via version control |87| `Math.random()` for tokens/IDs | Predictable, not cryptographically secure |88| Bare `fetch()` without `await` or `waitUntil` | Floating promise — dropped result, swallowed error |89| Module-level mutable variables for request state | Cross-request data leaks, stale state, I/O errors |90| Cloudflare REST API from inside a Worker | Unnecessary network hop, auth overhead, added latency |91| `ctx.passThroughOnException()` as error handling | Hides bugs, makes debugging impossible |92| Hand-written `Env` interface | Drifts from actual wrangler config bindings |93| Direct string comparison for secret values | Timing side-channel — use `crypto.subtle.timingSafeEqual` |94| Destructuring `ctx` (`const { waitUntil } = ctx`) | Loses `this` binding — throws "Illegal invocation" at runtime |95| `any` on `Env` or handler params | Defeats type safety for all binding access |96| `as unknown as T` double-cast | Hides real type incompatibilities — fix the design |97| `implements` on platform base classes (instead of `extends`) | Legacy — loses `this.ctx`, `this.env`. Applies to DurableObject, WorkerEntrypoint, Workflow |98| `env.X` without a scoped `env` variable in a platform class | Use `this.env.X`; a constructor or method parameter named `env` is valid |99100## Review Workflow1011021. **Retrieve** — fetch latest best practices page, workers types, and wrangler schema1032. **Read full files** — not just diffs; context matters for binding access patterns1043. **Check types** — binding access, handler signatures, no `any`, no unsafe casts (see `references/review.md`)1054. **Check config** — compatibility_date, nodejs_compat, observability, secrets, binding-code consistency1065. **Check patterns** — streaming, floating promises, global state, serialization boundaries1076. **Check security** — crypto usage, secret handling, timing-safe comparisons, error handling1087. **Validate with project tools** — use the repository's installed typecheck and lint scripts; do not download a floating tool version for review1098. **Reference rules** — see `references/rules.md` for each rule's correct pattern110111## Scope112113This skill covers Workers-specific best practices and code review. For related topics:114115- **Durable Objects**: load the `durable-objects` skill116- **Workflows**: see [Rules of Workflows](https://developers.cloudflare.com/workflows/build/rules-of-workflows/)117- **Wrangler CLI commands**: load the `wrangler` skill118119## Principles120121- **Be certain.** Retrieve before flagging. If unsure about an API, config field, or pattern, fetch the docs first.122- **Provide evidence.** Reference line numbers, tool output, or docs links.123- **Focus on what developers will copy.** Workers code in examples and docs gets pasted into production.124- **Correctness over completeness.** A concise example that works beats a comprehensive one with errors.
SomtoUgeh