Your knowledge of Cloudflare Workers APIs, types, and wrangler configuration may be outdated. Prefer retrieval over pre-training for any Workers code review task.
Reference Sources
Use the repo's local copies — do not run npm pack or install packages to fetch types.
| Source |
Where to find it |
Use for |
| Wrangler config schema |
node_modules/wrangler/config-schema.json |
Config fields, binding shapes, allowed values |
| Workers types |
node_modules/@cloudflare/workers-types/index.d.ts |
API usage, handler signatures, binding types |
| Cloudflare docs search |
Use the cloudflare-docs search tool or read files in this repo |
API reference, compatibility dates/flags, binding docs |
Read these files directly when you need to verify a type, config field, or API signature. The guides in this folder describe what to validate — not how to fetch packages.
Review Process
1. Build Context
Read full files, not just diffs or isolated snippets. Code that looks wrong in isolation may be correct given surrounding logic.
- Identify the purpose of the code: is it a complete Worker, a snippet, a configuration example?
- Check git history for context:
git log --oneline -5 -- <file>
- Understand which bindings, types, and patterns the code depends on
2. Categorize the Code
Every code block falls into one of three categories. Review in the context of its category.
| Category |
Definition |
Expectations |
| Illustrative |
Demonstrates a concept; uses comments for most logic |
Correct API names, realistic signatures |
| Demonstrative |
Functional but incomplete; would work if placed in the right context |
Syntactically valid, correct APIs and binding access |
| Executable |
Standalone and complete; runs without modification |
Compiles, runs, includes imports and config |
3. Validate with Tools
Run type-checking and linting. Tool output is evidence, not opinion.
npx tsc --noEmit # TypeScript errors
npx eslint <files> # Lint issues
For config files, validate against the latest wrangler config schema (see wrangler-config.md for retrieval) and check that all fields, binding types, and values conform.
4. Check Against Rules
See workers-types.md for type system rules, wrangler-config.md for config validation, and common-patterns.md for correct API patterns.
Quick-reference rules:
| Rule |
Detail |
| Binding access |
env.X in module export handlers; this.env.X in classes extending platform base classes. See common-patterns.md. |
No any |
Never use any for binding types, handler params, or API responses. Use proper generics. |
| No type-system cheats |
Flag as unknown as T, unjustified @ts-ignore, unsafe assertions. See workers-types.md. |
| Config-code consistency |
Binding names in wrangler config must match env.X usage in code. See wrangler-config.md. |
| Required config fields |
Verify against the wrangler config schema — do not assume which fields are required. |
| Concise examples |
Examples should focus on core logic. Minimize boilerplate that distracts from what the code teaches. |
| Floating promises |
Every Promise must be awaited, returned, voided, or passed to ctx.waitUntil(). See common-patterns.md. |
| Serialization |
Data crossing Queue, Workflow step, or DO storage boundaries must be structured-clone serializable. See common-patterns.md. |
| Streaming |
Large/unknown payloads must stream, not buffer. Flag await response.text() on unbounded data. |
| Error handling |
Minimal but present — null checks on nullable returns, basic fetch error handling. Do not distract with verbose try/catch. |
5. Assess Risk
| Risk |
Triggers |
| HIGH |
Auth, crypto, external calls, value transfer, validation removal, access control, binding misconfiguration |
| MEDIUM |
Business logic, state changes, new public APIs, error handling, config changes |
| LOW |
Comments, logging, formatting, minor style |
Focus deeper analysis on HIGH risk. For critical paths, check blast radius: how many other files reference this code?
Security logic escalation: for crypto, auth, and timing-sensitive code, do not stop at verifying API calls are correct. Examine the surrounding logic for flaws that undermine the security property (e.g., correct timingSafeEqual call but early return on length mismatch). See common-patterns.md Security section.
Anti-patterns to Flag
| Anti-pattern |
Why it matters |
any on Env or handler params |
Defeats type safety for every binding access downstream |
as unknown as T double-cast |
Hides real type incompatibilities — fix the underlying design |
@ts-ignore / @ts-expect-error without explanation |
Masks errors silently; require a comment justifying each suppression |
Buffering unbounded data (await res.text(), await res.json() on streams) |
Memory exhaustion on large payloads; use streaming |
| Hardcoded secrets or API keys |
Use env bindings and wrangler secret |
blockConcurrencyWhile on every request |
Only for initialization; blocks all concurrent requests |
| Single global Durable Object |
Creates a bottleneck; shard by coordination atom |
| In-memory-only state in DOs |
Lost on eviction; persist to SQLite storage |
| Missing DO migrations in config |
New DO classes require migration entries or deployment fails |
Floating promises (step.do(), fetch() without await) |
Silent bugs — drops results, breaks Workflow durability, ignores errors |
Non-serializable values across boundaries (Response, Error in step/queue) |
Compiles but fails at runtime; extract plain data before crossing boundary |
implements instead of extends on platform base classes |
Legacy pattern — loses this.ctx, this.env access from base class |
What NOT to Flag
- Style not enforced by linters
- "Could be cleaner" when code is correct and clear
- Theoretical performance concerns without evidence
- Missing features not in scope of the example
- Pre-existing issues in unchanged code
Output Format
**[SEVERITY]** Brief description
`file.ts:42` — explanation with evidence (tool output, type error, config mismatch)
Suggested fix: `code` (if applicable)
Severity: CRITICAL (security, data loss, crash) | HIGH (type error, wrong API, broken config) | MEDIUM (missing validation, edge case, outdated pattern) | LOW (style, minor improvement)
End with a summary count by severity. If no issues found, say so directly.
Principles
- Be certain. Investigate before flagging. If you cannot confirm an API, binding pattern, or config field, retrieve the docs or schema first.
- Provide evidence. Reference line numbers, tool output, schema fields, or type definitions.
- Correctness over completeness. A concise example that works is better than a comprehensive one with errors.
- Respect existing patterns. Do not flag conventions already established in the codebase unless actively harmful.
- Focus on what developers will copy. Code in documentation gets pasted into production. Treat it accordingly.
1---2name: workers-code-review3description: Reviews Workers and Cloudflare Developer Platform code for type correctness, API usage, and configuration validity. Load when reviewing TypeScript/JavaScript using Workers APIs, wrangler.jsonc/toml config, or Cloudflare bindings (KV, R2, D1, Durable Objects, Queues, Vectorize, AI, Hyperdrive).4---5
6Your knowledge of Cloudflare Workers APIs, types, and wrangler configuration may be outdated. **Prefer retrieval over pre-training** for any Workers code review task.
7
8## Reference Sources
9
10Use the repo's local copies — do **not** run `npm pack` or install packages to fetch types.
11
12| Source | Where to find it | Use for |
13| ---------------------- | ---------------------------------------------------------------- | ------------------------------------------------------ |
14| Wrangler config schema | `node_modules/wrangler/config-schema.json` | Config fields, binding shapes, allowed values |
15| Workers types | `node_modules/@cloudflare/workers-types/index.d.ts` | API usage, handler signatures, binding types |
16| Cloudflare docs search | Use the `cloudflare-docs` search tool or read files in this repo | API reference, compatibility dates/flags, binding docs |
17
18Read these files directly when you need to verify a type, config field, or API signature. The guides in this folder describe what to validate — not how to fetch packages.
19
20## Review Process
21
22### 1. Build Context
23
24Read full files, not just diffs or isolated snippets. Code that looks wrong in isolation may be correct given surrounding logic.
25
26- Identify the purpose of the code: is it a complete Worker, a snippet, a configuration example?
27- Check git history for context: `git log --oneline -5 -- <file>`
28- Understand which bindings, types, and patterns the code depends on
29
30### 2. Categorize the Code
31
32Every code block falls into one of three categories. Review **in the context** of its category.
33
34| Category | Definition | Expectations |
35| ----------------- | -------------------------------------------------------------------- | ---------------------------------------------------- |
36| **Illustrative** | Demonstrates a concept; uses comments for most logic | Correct API names, realistic signatures |
37| **Demonstrative** | Functional but incomplete; would work if placed in the right context | Syntactically valid, correct APIs and binding access |
38| **Executable** | Standalone and complete; runs without modification | Compiles, runs, includes imports and config |
39
40### 3. Validate with Tools
41
42Run type-checking and linting. Tool output is evidence, not opinion.
43
44```bash
45npx tsc --noEmit # TypeScript errors
46npx eslint <files> # Lint issues
47```
48
49For config files, validate against the latest wrangler config schema (see `wrangler-config.md` for retrieval) and check that all fields, binding types, and values conform.
50
51### 4. Check Against Rules
52
53See `workers-types.md` for type system rules, `wrangler-config.md` for config validation, and `common-patterns.md` for correct API patterns.
54
55**Quick-reference rules:**
56
57| Rule | Detail |
58| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
59| Binding access | `env.X` in module export handlers; `this.env.X` in classes extending platform base classes. See `common-patterns.md`. |
60| No `any` | Never use `any` for binding types, handler params, or API responses. Use proper generics. |
61| No type-system cheats | Flag `as unknown as T`, unjustified `@ts-ignore`, unsafe assertions. See `workers-types.md`. |
62| Config-code consistency | Binding names in wrangler config must match `env.X` usage in code. See `wrangler-config.md`. |
63| Required config fields | Verify against the wrangler config schema — do not assume which fields are required. |
64| Concise examples | Examples should focus on core logic. Minimize boilerplate that distracts from what the code teaches. |
65| Floating promises | Every `Promise` must be `await`ed, `return`ed, `void`ed, or passed to `ctx.waitUntil()`. See `common-patterns.md`. |
66| Serialization | Data crossing Queue, Workflow step, or DO storage boundaries must be structured-clone serializable. See `common-patterns.md`. |
67| Streaming | Large/unknown payloads must stream, not buffer. Flag `await response.text()` on unbounded data. |
68| Error handling | Minimal but present — null checks on nullable returns, basic fetch error handling. Do not distract with verbose try/catch. |
69
70### 5. Assess Risk
71
72| Risk | Triggers |
73| ---------- | ---------------------------------------------------------------------------------------------------------- |
74| **HIGH** | Auth, crypto, external calls, value transfer, validation removal, access control, binding misconfiguration |
75| **MEDIUM** | Business logic, state changes, new public APIs, error handling, config changes |
76| **LOW** | Comments, logging, formatting, minor style |
77
78Focus deeper analysis on HIGH risk. For critical paths, check blast radius: how many other files reference this code?
79
80**Security logic escalation**: for crypto, auth, and timing-sensitive code, do not stop at verifying API calls are correct. Examine the surrounding logic for flaws that undermine the security property (e.g., correct `timingSafeEqual` call but early return on length mismatch). See `common-patterns.md` Security section.
81
82## Anti-patterns to Flag
83
84| Anti-pattern | Why it matters |
85| ----------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
86| `any` on `Env` or handler params | Defeats type safety for every binding access downstream |
87| `as unknown as T` double-cast | Hides real type incompatibilities — fix the underlying design |
88| `@ts-ignore` / `@ts-expect-error` without explanation | Masks errors silently; require a comment justifying each suppression |
89| Buffering unbounded data (`await res.text()`, `await res.json()` on streams) | Memory exhaustion on large payloads; use streaming |
90| Hardcoded secrets or API keys | Use `env` bindings and `wrangler secret` |
91| `blockConcurrencyWhile` on every request | Only for initialization; blocks all concurrent requests |
92| Single global Durable Object | Creates a bottleneck; shard by coordination atom |
93| In-memory-only state in DOs | Lost on eviction; persist to SQLite storage |
94| Missing DO migrations in config | New DO classes require migration entries or deployment fails |
95| Floating promises (`step.do()`, `fetch()` without `await`) | Silent bugs — drops results, breaks Workflow durability, ignores errors |
96| Non-serializable values across boundaries (`Response`, `Error` in step/queue) | Compiles but fails at runtime; extract plain data before crossing boundary |
97| `implements` instead of `extends` on platform base classes | Legacy pattern — loses `this.ctx`, `this.env` access from base class |
98
99## What NOT to Flag
100
101- Style not enforced by linters
102- "Could be cleaner" when code is correct and clear
103- Theoretical performance concerns without evidence
104- Missing features not in scope of the example
105- Pre-existing issues in unchanged code
106
107## Output Format
108
109```
110**[SEVERITY]** Brief description
111`file.ts:42` — explanation with evidence (tool output, type error, config mismatch)
112Suggested fix: `code` (if applicable)
113```
114
115Severity: **CRITICAL** (security, data loss, crash) | **HIGH** (type error, wrong API, broken config) | **MEDIUM** (missing validation, edge case, outdated pattern) | **LOW** (style, minor improvement)
116
117End with a summary count by severity. If no issues found, say so directly.
118
119## Principles
120
121- **Be certain.** Investigate before flagging. If you cannot confirm an API, binding pattern, or config field, retrieve the docs or schema first.
122- **Provide evidence.** Reference line numbers, tool output, schema fields, or type definitions.
123- **Correctness over completeness.** A concise example that works is better than a comprehensive one with errors.
124- **Respect existing patterns.** Do not flag conventions already established in the codebase unless actively harmful.
125- **Focus on what developers will copy.** Code in documentation gets pasted into production. Treat it accordingly.
Cloudflare