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.

Read these files directly when you need to verify a type, config field, or API signature. The reference guides in references/ 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.

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 references/wrangler-config.md for retrieval) and check that all fields, binding types, and values conform.

4. Check Against Rules

See references/workers-types.md for type system rules, references/wrangler-config.md for config validation, and references/common-patterns.md for correct API patterns.

Quick-reference rules:

5. Assess Risk

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 references/common-patterns.md Security section.

Anti-patterns to Flag

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
• TOML config in existing docs (only flag for new content)

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.