Best Cloudflare Workers skills for AI agents

An agent that knows JavaScript will confidently write Node. Cloudflare Workers is not Node. What comes out typechecks, starts under wrangler dev, and then fails in production in ways that look like somebody else's bug: a database handle created once at import and quietly shared by every visitor, a config value read at module scope that is undefined by the time a request arrives, a transaction D1 simply refuses to open. None of it is a syntax error. All of it is an assumption about where the process lives and how long it lives for.

The skills worth installing make the same two corrections, at layers that have nothing to do with each other. Build it per request, never once at module scope — that instruction turns up in the auth wiring, in the ORM handle, and in the client-side query cache, three layers whose only common ground is the runtime underneath. And: do not trust what you remember about the API surface, go read the schema on disk. Those two habits are most of what separates a skill that helps from a skill that hands your agent a confident, plausible, broken file.

Top picks

skill	publisher	license	verdict	updated
wrangler	cloudflare	Apache-2.0	the config and CLI surface	2026-07-24
cloudflare-worker-dev	curiositech	MIT	the runtime traps	2026-07-14
drizzle-orm-d1	secondsky	MIT	D1's real constraints	2026-07-25
r2-storage	null-shot	Apache-2.0	R2, with the code in the file	2026-01-18
cloudflare-r2	secondsky	MIT	R2, as a list of what breaks	2026-07-25
tanstack-start	jezweb	MIT	the whole app, file by file	2026-07-02
tanstack-start	secondsky	MIT	per-route rendering control	2026-07-25
accelint-tanstack-query-best-practices	gohypergiant	Apache-2.0	the cache review checklist	2026-07-24
tanstack-query	tanstack-skills	MIT	the fuller API reference	2026-01-31

Wrangler: take Cloudflare's own, and take its distrust of memory with it

Cloudflare's wrangler skill opens by telling the agent its knowledge of flags, config fields and binding shapes is probably outdated, and pointing it at node_modules/wrangler/config-schema.json as the authority. That single instruction is worth more than the reference tables underneath it, which are themselves good: bindings for KV, R2, D1, Workers AI, Vectorize, Hyperdrive and Durable Objects in one annotated config block, wrangler types after every config change, wrangler check startup to catch a Worker that blows the startup limit, and a secrets section that bans passing values as command arguments in favour of the interactive prompt or a file.

It also settles a question your agent will otherwise get wrong: prefer wrangler.jsonc over TOML, because newer features are JSON-only. The caveat is scope. This is a command and config surface, not a program design guide — it will tell you how to declare a Durable Object binding and nothing about whether you should have one.

Worker runtime: curiositech's anti-patterns are the ones that actually bite

The half of cloudflare-worker-dev worth installing is the anti-patterns section, because every entry is a bug that passes review. Awaiting a KV write in the request path instead of handing it to ctx.waitUntil. Reading a key back immediately after writing it and believing the result — KV is eventually consistent, and the read may hand you the old value. Skipping the OPTIONS preflight, which breaks every browser call against a handler that reads as correct. Putting an API key in [vars] and committing it. It also carries a small error-code table, so a bare 1101 or 1102 in your logs stops being a mystery.

The caveat is cosmetic but real: its config examples are written as wrangler.toml while Cloudflare's own CLI guidance pushes wrangler.jsonc. Take the patterns, translate the file format.

D1 with Drizzle: the one that knows D1 is not your Postgres

drizzle-orm-d1 leads with the constraint that breaks the most generated code: D1 rejects SQL BEGIN TRANSACTION, so db.transaction() is not the answer — you group the statements and submit them together through D1's own array API, which the skill names in its error table and then hands off to a bundled template. From there it stays specific in the same way. Store timestamps as integer with mode: 'timestamp', because D1 has no native date type. Use .$defaultFn() rather than .default() when the default is a function call. Generate migrations with drizzle-kit and apply them with Wrangler — do not mix drizzle-kit migrate into a workflow that also runs wrangler d1 migrations apply, and keep drizzle-kit push away from production.

What you get in the file itself is rules and a quick-start, not recipes; the deeper material sits in reference files the body only names. It also ends with a supply-chain note — block post-install scripts, let new package versions age before adopting them — which is unusual for an ORM skill and welcome.

R2: null-shot's if you want code, secondsky's if you want the failure list

r2-storage is the one to hand an agent that has to write an upload path this afternoon. The presigned-URL flow is there as working code rather than a promise of working code — S3 client construction against the R2 endpoint, getSignedUrl, and the browser-side PUT that follows. So are range requests answering with a 206 and a Content-Range, ETag conditionals via onlyIf, and cursor pagination that actually handles a truncated listing. It is also honest about when not to reach for the AWS SDK: the native binding is the more efficient path for ordinary get and put.

cloudflare-r2 is built the other way round, as a catalogue of what goes wrong — files downloading as binary when contentType is unset, bulk delete failing above 1000 keys, CORS unconfigured before a browser upload. Its presigned and multipart implementations, though, are pointers to bundled templates rather than code you can read in the file. Install one, keep the other's list beside it as a preflight.

The whole app: jezweb's builds it from nothing, file by file

jezweb's tanstack-start generates every file instead of cloning a template, and the details it insists on are exactly the ones an agent invents wrong. main must be @tanstack/react-start/server-entry. The Cloudflare Vite plugin has to come first or you get errors that name none of this. Read bindings through import { env } from "cloudflare:workers", inside the handler — and build the Drizzle client and the auth instance per request, never at module level. Better-auth has to be mounted as an API route, not a server function, because it needs the raw request and response.

Its common-issues table is the part I'd keep on a second monitor; the entry explaining that wrangler secret put does not redeploy will save someone an afternoon. secondsky's tanstack-start is a different animal — per-route ssr: true | false | 'data-only', link preloading, route masking, an ESLint rule that enforces route property order — and its own front matter marks it status: rc and production-tested: false. Build with jezweb's, tune with secondsky's.

Client cache: accelint's is the one with opinions worth obeying

accelint-tanstack-query-best-practices opens with a list of things never to do, and the first entry is the one that matters on a server-rendered edge app: never use a singleton QueryClient on the server, because it leaks one user's cached data into another user's response. That is the same per-request rule the auth and database layers are enforcing, arriving from a completely different direction. The rest holds up — no queries inside list-item components, no keys built from Date.now(), no optimistic updates on high-stakes mutations, and a select function hoisted to module scope so it isn't rebuilt every render.

The caveat is its frame: it is written against Next.js App Router, so the server-cache half doesn't transfer to Workers. tanstack-skills' tanstack-query is the better lookup document — queryOptions, suspense, infinite queries, and a pitfalls list that catches the initialData versus placeholderData confusion. Take that one as the reference and accelint's as the review.

How do you tell two skills with the same name apart?

You open the body, because the name only tells you the topic. A skill called cloudflare can be a map, a cookbook, or a briefing, and the three are not substitutes.

The map is cloudflare's own: decision trees that route "I need to store data" to the right product and then to a reference file, with almost no code in the document itself. dmmulroy's is the same shape and has a step the other lacks — verify wrangler whoami before any deploy. The cookbook is hoodini's: no decision trees, just Workers, KV, D1, R2, Durable Objects and Pages as snippets you can paste. The briefing is oakoss's: short, with an explicit when-not-to-use in its overview and a common-mistakes section where the cookbook would have put examples.

Two tells settle it fast. First, does the opening paragraph tell the agent to go retrieve current documentation, or does it present itself as the source of truth? Second, does its config appear as wrangler.toml or wrangler.jsonc? A document still writing TOML is a document that stopped tracking the platform, whatever its name says.

What to check before you hand one to your agent

Check the license line, and check it in both places, because the two can disagree. oakoss's document declares MIT in its own front matter while the repository record for it carries no license at all; hoodini's declares nothing in either. A license written into a skill file is a claim by the file, not necessarily a grant from the repository it lives in — which is exactly why the repository, not the skill, is the thing to look at. If the skill's text is going to end up quoted in your codebase, resolve that first.

Then check whether the skill's advice survives contact with a Worker. The reliable test is the per-request question: does it create clients, database handles and auth instances inside the handler, or once at the top of the file? A skill that shows a Drizzle client or a QueryClient constructed at module scope is not wrong about the library — it's wrong about the runtime. Get it wrong on the query client and one user's cached data turns up in another user's response. Get it wrong on the bindings and env is simply undefined by the time a request arrives. Neither reads as a configuration mistake in the logs.

What you have now

The failure modes at the start of this were all the same failure: code written for a long-lived process running on infrastructure that has none. Cloudflare's wrangler skill removes the config guesswork and installs the habit of checking the schema instead of recalling it. curiositech's anti-patterns catch the runtime mistakes that survive local testing. drizzle-orm-d1 stops your agent writing transactions D1 will reject. r2-storage gives it upload code that already handles ranges, conditionals and pagination. jezweb's tanstack-start wires the whole thing together with per-request construction as a rule rather than an accident, and accelint's checklist keeps the same rule from breaking on the client.

Install those and the remaining bugs in your edge app will at least be yours.