2.1.0
Added
- The tool has its own icon, in a dark and a light version. Codex shows it on the plugin card and in the skill list, and the toolkit site shows it on the tool's page and in share previews.
cloudflare-ops
Connect a Cloudflare account once, then manage DNS records, subdomains, Pages sites, R2 buckets and Workers from the agent without opening the dashboard again. Setup is a two-minute guided flow that needs three checkboxes, not the 390-odd permissions Cloudflare would otherwise ask you to pick by hand. Works on macOS, Windows and Linux.
Say this you do not type commands, you ask
- “connect my Cloudflare”
- “add a subdomain”
- “point a domain at my server”
- “create a DNS record”
- “set up Cloudflare Pages”
- “add a custom domain to Pages”
- “create an R2 bucket”
- “check if DNS has propagated”
- “list my domains”
- “deploy this worker”
- “publish my site”
- “cloudflare”
Once it is installed, that is the whole interface. Your agent picks the skill up on its own and runs whatever it needs to. The commands further down are there for anyone who would rather drive it themselves.
Install pick your agent
Requirements what to install, and why
node scripts/setup.mjs begin # prints the three permissions to tick, and where to paste
node scripts/setup.mjs finish # builds the real token, deletes the temporary one
node scripts/setup.mjs status # which account is connected
begin --force replaces an existing credential. Running begin when already connected does nothing.
Examples copy and go
Changelog what changed, newest first
2.0.0breaking
Breaking
- Installed as a Claude Code plugin, the slash command is now
/cloudflare-ops:cloudflare-ops, with the plugin name in front. This has been true since 1.2.0, and this release marks it as breaking. Use the new name, or ask in words, which works as before. A copy in a skills folder keeps the plain name/cloudflare-ops.
Added
- Codex now shows a display name, a short line and a starter prompt for the skill in its skill list. They come from a generated
agents/openai.yamlinside the skill folder. Other agents ignore that file.
Changed
- The description now leads with what the skill does, then its trigger phrases, then the detail. Codex shortens long skill lists from the end, so the phrases that route a request now survive far longer. With 40 skills installed, 95% of the phrases stay visible instead of 8%.
1.2.0
Added
- Can be installed as a Codex plugin, from the same source as everything else.
Changed
- The changelog address now points to the site, so it keeps working if the repository layout changes.
1.1.0
Added
- This changelog, so you can see what changed in each version.
- An Updates section in
SKILL.md. It tells the agent how to check for a newer version, and to report what changed before it updates.
1.0.0
Added
- Connect a Cloudflare account in two steps. The token needs three checkboxes and is never typed into the chat.
- Manage DNS records and subdomains.
- Publish a Pages site from start to finish, with a custom domain.
- Deploy a Worker and route a hostname to it.
- Manage R2 buckets.
- Look up any Cloudflare API endpoint instead of guessing at it.
- Declare the Node requirement, and offer to install Node when it is missing.
An agent that has this installed reads CHANGELOG.md in the skill folder.
The same history is at changelog.json,
and every tool's releases are at /updates.json.
Just ask
You do not need to run anything. Once the skill is installed, say what you want in your own words and the agent does it:
"connect my Cloudflare account" "point app.mysite.com at my server, the address is 203.0.113.10" "has the DNS updated yet?" "what domains do I have?" "publish this site to Cloudflare and put www.mysite.com on it" "deploy this worker and put api.mysite.com on it" "delete the old staging subdomain"
The agent runs the commands, checks the result, and tells you in plain words whether it worked. It will ask before deleting anything, and it will tell you when a choice matters — such as whether traffic should pass through Cloudflare or go straight to your server.
The only thing it cannot do for you is the one-time account connection: you tick three boxes on Cloudflare's website and paste the result into a file. That is deliberate — it means your token never passes through a chat window. The agent walks you through it and does everything after.
The commands below are for people who would rather drive themselves.
The setup problem this solves
Cloudflare has no "grant everything" control. Building a token by hand means choosing from 392 separate permissions across four scopes, and picking wrong produces an error that means nothing to a beginner. Cloudflare does, however, let a token that can manage tokens create other tokens.
So the flow is: the user ticks three checkboxes to make a temporary token, pastes it into a file, and the script builds the real one — then deletes the temporary one. Two minutes, no jargon.
The token is never typed into the conversation. The script writes an empty file and names it; the user pastes the value in themselves. Storage and handling come from toolkit-credentials.
Requirements
Node 18 or newer. If you do not have it, the skill installs it for you — the agent runs this, or you can:
sh scripts/setup-deps.sh --check # is everything present?
sh scripts/setup-deps.sh # show the install command, ask, then run it
.\scripts\setup-deps.ps1 # Windows
It picks the right command for your machine (Homebrew, apt, dnf, pacman, zypper, apk, winget) and never installs anything without asking. Where there is no package manager it prints instructions you can follow yourself, including one that needs no admin rights.
Publishing to Pages or Workers also uses wrangler, but there is nothing to install — it is fetched on demand through npx, which ships with Node, and receives the saved token so it needs no login of its own.
If you prefer the command line
node scripts/cf.mjs whoami
node scripts/cf.mjs zones
node scripts/cf.mjs dns example.com
node scripts/cf.mjs dns-add app.example.com A 203.0.113.10
node scripts/cf.mjs dns-add www.example.com CNAME my-site.pages.dev --proxied
node scripts/cf.mjs dns-remove old.example.com --type A --yes
node scripts/cf.mjs check app.example.com
node scripts/cf.mjs r2
node scripts/cf.mjs pages
node scripts/cf.mjs pages-create my-site
node scripts/cf.mjs pages-deploy my-site ./dist
node scripts/cf.mjs pages-domain my-site www.example.com
node scripts/cf.mjs pages-domains my-site
node scripts/cf.mjs workers
node scripts/cf.mjs worker-deploy ./my-worker
node scripts/cf.mjs worker-domain my-worker api.example.com
node scripts/cf.mjs worker-domains
node scripts/api.mjs search waf rule
node scripts/api.mjs show "/zones/{zone_id}/rulesets" post
dns-remove lists what it matched and refuses to delete without --yes.
check queries public resolvers through Node's own DNS client, so it reports what a visitor would see — and works on Windows, where dig is not installed.
Publishing a site
The whole path, verified end to end — a new project was live on its own hostname over HTTPS about a minute after the domain was attached:
npm run build # your build, whatever it is
node scripts/cf.mjs pages-create my-site
node scripts/cf.mjs pages-deploy my-site ./dist
node scripts/cf.mjs pages-domain my-site www.example.com
node scripts/cf.mjs pages-domains my-site # certificate status
Re-deploying later is only the third line. Or say "publish this site to Cloudflare and put www.example.com on it" and the agent does all of it.
pages-deploy runs wrangler through npx — nothing to install, no second login, the saved token is handed to it. pages-domain attaches the domain and creates the DNS record, because doing only one leaves it stuck at "pending" forever.
Deploying a Worker
node scripts/cf.mjs worker-deploy ./my-worker
node scripts/cf.mjs worker-domain my-worker api.example.com
The directory needs a wrangler.toml naming the Worker and its entry file. Include workers_dev = false when it will live on your own domain — without it, a first deploy on a fresh account tries to register a workers.dev subdomain named after the folder and fails. worker-deploy checks for that before running and explains it.
Unlike Pages, do not add a DNS record for a Worker hostname: worker-domain is the whole job and Cloudflare manages the record itself.
Anything not wrapped
Cloudflare has about 2000 endpoints and request() reaches all of them with the same credential. The only hard part is knowing which one and what it wants, so the skill can look that up instead of guessing:
node scripts/api.mjs search waf rule
node scripts/api.mjs show "/zones/{zone_id}/rulesets" post
It reads Cloudflare's own API description — downloaded once, cached next to the credentials — and resolves the internal references so the request body is readable rather than a pointer. This is the job the official Cloudflare MCP server does; doing it here means no second server, no OAuth, and it works in every agent rather than one.
What it cannot do
Building is yours. pages-deploy and worker-deploy upload what already exists — run your build first.
The token also cannot create further tokens: Cloudflare refuses to grant token-management permission to a token created by another token. Rotate with begin --force.
Playbooks
references/playbooks.md — pointing a subdomain at a server and waiting for its certificate, replacing a record without downtime, Pages with a custom domain, Workers on your own domain, R2 with a public hostname, and a diagnostic order for "it is not resolving".
Built at Itqan Lab, a design and technology studio.
إتقان — itqan, the Arabic word for mastery: doing a thing precisely, and completely.