Preface¶

When starting a project on Cloudflare, the first step is often not writing code, but selecting products. To run logic, you might choose Workers, Pages, Durable Objects, Workflows, or Containers; for data storage, KV, D1, R2, and Hyperdrive all look usable; to connect AI models, you’ll encounter Workers AI, Vectorize, and the Agents SDK. Documentation is split by product, and APIs, binding fields, and quotas often change. If an AI programming assistant only relies on its training data, it will easily provide outdated wrangler configurations, decommissioned model IDs, or write coordination scenarios that should use Durable Objects as regular KV.

Cloudflare officially maintains a set of Agent Skills in the cloudflare/skills repository. The one named cloudflare is the full-platform entry point in the entire list: it first uses a decision tree to help the Agent select the correct product, then loads the corresponding reference files as needed, and incorporates the rule of “first check the official documentation, do not memorize the numbers in the reference files” into the Skill itself.

What is this¶

cloudflare is a comprehensive platform Skill officially produced by Cloudflare, with its directory at:
https://github.com/cloudflare/skills/tree/main/skills/cloudflare

The positioning in the YAML header is straightforward: it covers Workers, Pages, storage (KV, D1, R2), AI (Workers AI, Vectorize, Agents SDK), feature flags (Flagship), networking (Tunnel, Spectrum), security (WAF, DDoS), and infrastructure as code (Terraform, Pulumi). The applicable scenario is marked as any Cloudflare development task, and it clearly states: it prefers to retrieve from Cloudflare documentation rather than relying on the model’s pre-trained knowledge.

It does not solve the problem of “adding another quick reference for Wrangler commands”, but two more common issues:
1. There are too many products, and if the Agent selects the wrong primitive first, subsequent bindings, quotas, and consistency models will all be wrong.
2. The platform changes rapidly, and reference files can only serve as a starting point. The Skill body requires: before citing specific numbers, API signatures, or configuration items, first verify them in the official documentation, Workers type packages, Wrangler configuration schema, or the changelog; when there is a conflict between reference files and documentation, prevail over the documentation.

There are more specialized Skills in the same repository, such as wrangler (deployment and resource management), agents-sdk (stateful Agents), and durable-objects. The cloudflare Skill is the general index: use it first when the task has not been narrowed down to a single product.

Core Design: Decision Tree + On-Demand Loading¶

The Skill directory is simple, with only one entry file and a large collection of reference materials:

skills/cloudflare/
├── SKILL.md
└── references/          # Currently 63 product subdirectories
    ├── workers/
    ├── pages/
    ├── kv/
    ├── d1/
    ├── r2/
    ├── workers-ai/
    ├── vectorize/
    ├── wrangler/
    └── ...

SKILL.md itself does not include the API of each product. The body first provides a set of decision trees for “what do I need to do”, then points to references/<product>/. The repository currently lists 63 product directories, covering Workers, D1, Workers AI, Tunnel, WAF, Terraform, Email Workers, and more.

Take “I need to store data” as an example, the tree in the Skill is roughly:

Need storage?
├─ Key-value (configuration, session, cache) → kv/
├─ Relational SQL → d1/ (SQLite) or hyperdrive/ (existing Postgres/MySQL)
├─ Objects/files (S3 compatible) → r2/
├─ Vector retrieval → vectorize/
├─ Strongly consistent entity state → durable-objects/
└─ Asynchronous messages → queues/

“I need to run code” also branches by scenario: edge functions go to workers/, Git-driven full-stack sites go to pages/, stateful collaboration goes to durable-objects/, long-step tasks go to workflows/, running containers goes to containers/, and scheduled tasks go to cron-triggers/.

Each product directory is usually split into several on-demand reading files. For example, the recommended reading order in the Workers reference is:

This is the progressive loading common in Agent Skills: at the start of a conversation, only the Skill’s name and description are visible; after matching the task, read SKILL.md; only when actually writing code for a product, open the corresponding configuration.md, api.md, patterns.md or gotchas.md. The entire Cloudflare documentation is compressed into one Skill, but it will not flood the context all at once.

Installation and Enablement¶

The official README states that this set of Skills is for assistants that support the Agent Skills standard, including Claude Code, Cursor, OpenCode, OpenAI Codex, and Pi. Installation methods vary by tool, do not mix them.

1. Use npx skills (cross-tool universal)

Install the entire Cloudflare Skills collection:

npx skills add https://github.com/cloudflare/skills

To install only this platform Skill, the command given on the officialskills.sh page is:

npx skills add https://github.com/cloudflare/skills --skill cloudflare

2. Claude Code (Plugin Marketplace)

/plugin marketplace add cloudflare/skills
/plugin install cloudflare@cloudflare

The same plugin also includes remote MCP services (cloudflare-docs, cloudflare-bindings, cloudflare-api, etc.) and two slash commands: /cloudflare:build-agent and /cloudflare:build-mcp. They are in the same repository as the cloudflare Skill, but are not part of the SKILL.md itself.

3. Cursor
The official README recommends installing from the Cursor Marketplace, or filling in cloudflare/skills in Settings > Rules > Add Rule > Remote Rule (Github).

4. Clone and copy the directory manually

You should copy the entire skills/cloudflare/ folder, ensuring the relative path between SKILL.md and references/ remains intact. The Agent will usually enable it automatically; when the task is “help me select Cloudflare storage / write Worker bindings / connect Workers AI”, this Skill will be matched.

Typical Usage¶

The following examples are all reproducible samples from the official Skill reference files, used to demonstrate how the Agent should write code after loading this Skill, rather than compiling a separate tutorial.

1. Let the Agent select products first, then write code¶

You can directly use the decision tree as a prompt constraint, for example:

I want to build an edge API with user configuration, file upload, and scheduled cleanup. Please follow the decision tree in the cloudflare Skill to first select compute and storage primitives, then provide the wrangler configuration and Worker skeleton. Do not fill in quotas and model IDs from memory; if there are numbers, check them against the Cloudflare documentation first.

The typical trigger scenarios listed by the Skill itself include: selecting Workers / Pages / D1 / R2 / Durable Objects for a new project; connecting Workers AI or Vectorize to an existing application; opening Tunnel or Spectrum for an internal service; configuring WAF and DDoS for a production domain; managing Cloudflare resources with Terraform or Pulumi.

2. Workers entry and bindings¶

The modular Worker writing style recommended by the reference files is:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    return new Response('Hello World!');
  },
};

The meanings of the three parameters are clearly explained in references/workers/README.md: request is the standard Request, env mounts bindings such as KV / D1 / R2 / secrets, and ctx provides execution context such as waitUntil. You can use the official scaffold to create a new project:

npm create cloudflare@latest my-worker -- --type hello-world
cd my-worker
npx wrangler dev

Bindings are written in wrangler.jsonc (this format is recommended in the reference files). An example that mounts KV, R2, and D1 at the same time is as follows, with field names from references/workers/configuration.md:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2025-01-01",
  "kv_namespaces": [{ "binding": "MY_KV", "id": "abc123" }],
  "r2_buckets": [{ "binding": "MY_BUCKET", "bucket_name": "my-bucket" }],
  "d1_databases": [{ "binding": "DB", "database_name": "my-db", "database_id": "xyz789" }]
}

After modifying the bindings, you need to regenerate the types:

npx wrangler types

Access them in code via env.MY_KV, env.MY_BUCKET, and env.DB. The binding name is the identifier in the code, which is different from the resource ID on the Cloudflare console. Do not write Secrets into the configuration file, use:

npx wrangler secret put API_KEY

3. How to select and write KV, D1, and R2¶

The Skill clearly defines the division of labor for the three types of storage:
- KV: High read, low write, eventually consistent, suitable for configuration, sessions, and caching. There are frequency limits for single-key writes, and global visibility is not immediate.
- D1: Serverless database with SQLite semantics, suitable for splitting databases by user / tenant; when you need to read immediately after writing, the reference files point to the Sessions API, rather than assuming every query is strongly consistent.
- R2: S3-compatible object storage, suitable for files, backups, and media; directly put / get in Worker.

Minimum read and write operations for KV:

await env.MY_KV.put("key", "value", { expirationTtl: 300 });
const value = await env.MY_KV.get("key");

D1 uses prepared statements to avoid SQL injection:

const user = await env.DB.prepare(
  "SELECT * FROM users WHERE id = ?"
).bind(userId).first();

R2 upload and download:

await env.MY_BUCKET.put(key, data, {
  httpMetadata: { contentType: "image/jpeg" },
});
const object = await env.MY_BUCKET.get(key);
if (object) return new Response(object.body);

The corresponding CLI commands can also be found in each product’s README, such as wrangler kv namespace create, wrangler d1 create, and wrangler r2 bucket create. Local development uses simulated resources by default; to connect to online KV / AI and other resources, the reference files repeatedly emphasize adding --remote.

4. Workers AI: Write the code correctly, double-check the model name¶

The Skill recommends calling via Worker native bindings, do not install the deprecated @cloudflare/ai package anymore:

{ "ai": { "binding": "AI" } }

export default {
  async fetch(request: Request, env: Env) {
    const response = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      messages: [{ role: "user", content: "What is Cloudflare?" }],
    });
    return Response.json(response);
  },
};

npx wrangler dev --remote   # No models locally, AI must use remote mode
npx wrangler deploy

The structure of the above env.AI.run(...) comes from references/workers-ai/ and is still applicable today. But do not copy the model ID in the example as the current recommended one: Cloudflare announced in the changelog on 2026-05-08 that @cf/meta/llama-3.1-8b-instruct, @cf/meta/llama-3.1-70b-instruct, @cf/mistral/mistral-7b-instruct-v0.1 and others were decommissioned on **2026-05-30. Available alternatives in the same series include@cf/meta/llama-3.1-8b-instruct-fast; the changelog also provides alternative directions such as@cf/zai-org/glm-4.7-flash,@cf/google/gemma-4-26b-a4b-it, and@cf/moonshotai/kimi-k2.6`. The full list is subject to Workers AI Models.

This is exactly the design purpose of this Skill: reference files will expire, and the Agent must first retrieve and then cite. You can add a line to your prompt: “The model name is subject to developers.cloudflare.com/workers-ai/models”, to prevent the assistant from treating the old samples in the Skill repository as current production configurations.

Applicable Scenarios and Notes¶

Situations that are suitable for this Skill:
1. A new project where you have not decided whether to use Workers or Pages, or KV or D1.
2. You need to connect computing, storage, AI, and queues in the same Worker, and need the correct binding structure.
3. You need to write both application code and platform-side configurations such as Tunnel, WAF, and Terraform.
4. You have already encountered the assistant fabricating outdated APIs or quotas, and want it to follow the workflow of “first select products, then read references, then check documentation”.

Situations that are not suitable, or require switching to a specialized Skill:
1. The task is clearly wrangler deploy or troubleshooting bindings, using the wrangler Skill in the same repository is more direct.
2. Your goal is to use the Agents SDK to build a stateful Agent, using the agents-sdk Skill is more relevant.
3. This Skill is a workflow for coding assistants, not a replacement for the Cloudflare console, and it will not help you create an account or make payments.

There are several pitfalls that appear repeatedly in the reference files, which are worth adding to your prompt in advance:
- Workers do not have reliable module-level state between requests; store persistent data in KV / D1 / Durable Objects.
- Binding names and resource IDs are different; for multiple environments, non-inherited fields (various bindings) need to be rewritten under each env.
- New projects must set compatibility_date, otherwise runtime behavior will drift with the platform’s default values.
- Workers AI and some remote resources are not available in pure local wrangler dev, you need to use --remote.
- Numerical facts (CPU time limits, free quotas, model prices, number of nodes) should not be copied verbatim from the Skill reference files. For example, the Workers reference still says “300+ locations”, while the current Cloudflare official network page marks 337 cities; when there is a conflict, follow the Skill’s own rule of trusting the documentation.

Summary¶

The value of the cloudflare Skill does not lie in copying the official documentation again, but in providing the Agent with an executable path: first use the decision tree to narrow down the product, then load configurations and APIs via references/, and finally calibrate the expired parts using Cloudflare documentation. Cloudflare has a wide range of products and changes rapidly; this structure of “one Skill covering the entire cloud, but expanding on demand” is more practical than stuffing the entire developer documentation into the system prompt.

Official directory: https://github.com/cloudflare/skills/tree/main/skills/cloudflare

Repository description and installation methods for each tool: https://github.com/cloudflare/skills