workers-best-practices
Skill17 starsChanged 56 days agoMITView on GitHub
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.
- Reads credentials
37 other projects use a version of this, 27 of them edited.
Adopted by
Most recently taken up by
- artivilla/agent-skillsedited, first seen Nov 8, 2026
- 1stANUNNAKI/majlisedited, first seen Nov 8, 2026
- delorenj/skillsedited, first seen Nov 7, 2026
- jackson2w/claude-code-skillstheir own version, first seen Nov 3, 2026
- jjsizemore/jjskillsedited, first seen Nov 1, 2026
- adrienlupo/Claude-code-configtheir own version, first seen Oct 30, 2026
Used with
Projects with it also use nextjs-on-cloudflare, workers-profiling and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CloudflareSkillnextjs-on-cloudflare
Build, migrate, and deploy Next.js apps on Cloudflare Workers with vinext. Use when starting a Next.js project on Cloudflare, moving an existing app to Workers, choosing between vinext and OpenNext, or setting up vinext for Workers. For setup, migration, or deployment, install vinext's upstream skills with `npx skills add cloudflare/vinext` if missing, then read and follow the applicable skill and docs.
Also in 5 projects that use this
CloudflareSkillworkers-profiling
Profile or debug CPU usage and memory allocation in deployed Cloudflare Workers and Durable Objects. Then use this information to optimize your code.
Also in 4 projects that use this
- +9 more from cloudflare
Other versions37 projects use a version of this.
Word for word · 0
None found.
Edited · 27
- openai/plugins★ 7.8k100% same
- rianvdm/lastfm-mcp★ 53100% same
- Kilo-Org/cloud★ 2396% same
- delorenj/skills★ 17100% same
- kevyder/banrepco_mcp★ 9100% same
- Marvellbrazil/my-agentic-skills★ 4100% same
- meowdiocre/meowpi★ 393% same
- 1stANUNNAKI/majlis★ 298% same
- idexal/idexal-skills★ 2100% same
- langgenius/mosoo-skills★ 2100% same
17 more not listed
Wrote their own version · 10
- cloudflare/skills★ 3.3ksame name
- swyxio/skills★ 194same name
- louisbrulenaudet/monorepo-template★ 19same name
- adrienlupo/Claude-code-config★ 3same name
- Hahuyphananh/GRYND★ 2same name
- jackson2w/claude-code-skills★ 1same name
- mirzaaghazadeh/iwsdk-webxr-skills★ 1same name
- prdlk/skills★ 1same name
- hencter/hencte.top★ 0same name
- kschiavo-beep/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository53 other files it gives its agents.
- agents-sdkSkill
- agent-workflowSkill
- api-designSkill
- aws-iamSkill
- bash-shell-scriptingSkill
- cicd-github-actionsSkill
- cloudflare-email-serviceSkill
- cloudflareSkill
- cloudflare-waf-authorSkill
- cloudflare-workers-authorSkill
- cloud-platformsSkill
- codebase-security-auditSkill
- containers-orchestrationSkill
- core-engineeringSkill
- database-postgresqlSkill
- databricksSkill
- data-engineeringSkill
- distributed-transactionsSkill
- documentation-standardsSkill
- domain-driven-designSkill
- durable-objectsSkill
- frontend-engineeringSkill
- git-workflowSkill
- go-rust-systemsSkill
- iam-security-advisorSkill
- independent-verificationSkill
- infrastructure-iacSkill
- kubernetes-containersSkill
- kubernetes-operator-developmentSkill
- mcp-developmentSkill
- memory-architectureSkill
- multi-perspective-reviewSkill
- networking-transportSkill
- observabilitySkill
- oktaSkill
- pdf-exportSkill
- python-developmentSkill
- reactflow-architecture-diagramsSkill
- sandbox-sdkSkill
- scripting-automationSkill
- security-testingSkill
- service-resilienceSkill
- single-file-dashboardSkill
- skills-compositionSkill
- skills-continuous-improvementSkill
- snowflakeSkill
- system-designSkill
- typescript-javascriptSkill
- web-perfSkill
- web-research-kb-refreshSkill
- workload-identitySkill
- wranglerSkill
- zero-trustSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.
0
Common
Most of the 37 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
Before reviewing or writing Workers code, retrieve the current best practices page and relevant type definitions.
- Distinctive: line 106
Read full files: - not just diffs; context matters for binding access patterns
“Common” is measured: kept by at least 6 in 10 of the 37 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 and relevant type definitions. If the project's node_modules has an older version, prefer the latest published version.
# Fetch latest workers types
mkdir -p /tmp/workers-types-latest && \
npm pack @cloudflare/workers-types --pack-destination /tmp/workers-types-latest && \
tar -xzf /tmp/workers-types-latest/cloudflare-workers-types-*.tgz -C /tmp/workers-types-latest
# Types at /tmp/workers-types-latest/package/index.d.tsReference 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 | Every Promise must be awaited, returned, voided, or passed to ctx.waitUntil() |
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 inside platform base class | Should be this.env.X in classes extending DurableObject, WorkerEntrypoint, etc. |
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 (seereferences/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 tools -
npx tsc --noEmit, lint forno-floating-promises - Reference rules - see
references/rules.mdfor each rule's correct pattern
Scope
This skill covers Workers-specific best practices and code review. For related topics:
- Durable Objects: load the
durable-objectsskill - Workflows: see Rules of Workflows
- Wrangler CLI commands: load the
wranglerskill
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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

