Cloudflare Contributing to Cloudflare Docs
This is the single skill to load for any change to the Cloudflare Docs repository. It does not contain the detail itself — it routes you to the right reference for the task in front of you. Read the reference that matches your task, then follow it.
Do not guess at conventions. The references below are the source of truth for how this repo expects content to be written, structured, and validated.
Ground rules
These apply to every task below.
- This is an open-source, public repository. Never put private Cloudflare information, secrets, credentials, internal URLs, or environment variable values into pages, code examples, commits, pull requests, comments, or anywhere else in this repository. If there is any doubt — even slight — about whether something is safe to publish, stop and ask the user.
- Branch off the latest
production. Before starting work, create your branch from an up-to-dateproductioncommit (git fetch originthen branch fromorigin/production), unless the user asks for a different base. This repo's default branch isproduction, notmain. - Never commit or push automatically. Make the file changes, then ask the user whether they want to commit and push. Do not run
git commitorgit pushunprompted.
Before you start: gather context
When the source material is thin or ambiguous, pause and ask the user before writing. You need enough to write something accurate, not just well-formatted. Ask for whatever is missing:
- Source of truth — a PR, RFC, engineering spec, API schema, existing page, or product owner to verify behavior against. Do not invent technical claims.
- Product and feature area — which Cloudflare product, and where in that product the change belongs.
- Audience and intent — who reads this and what they are trying to do (get started, look something up, follow a procedure, understand a concept).
- Availability — plan availability (Free/Pro/Business/Enterprise) and lifecycle status (GA, Beta, Alpha).
- Scope — is this a new page, an edit, a restructure, or a changelog entry.
If the user already provided a clear spec or PR, proceed without interrogating them.
Task index
Find your task and read the listed reference(s). Paths are relative to this skill directory unless prefixed with .agents/.
| Your task | Read |
|---|---|
| Write or edit a documentation page | references/writing-docs.md (the authoring workflow — start here) |
Decide which pcx_content_type and page shape |
references/content-types.md |
| Decide how to present data / which component | references/choosing-components.md |
| Decide where a page belongs, redirects, reuse | references/information-architecture.md |
| Look up writing and formatting rules | .agents/references/style-guide.md (canonical) and .agents/references/procedures.md for step-by-steps |
| Look up a component's props and examples | .agents/references/components.md |
| Add or edit a changelog entry | references/changelog.md |
| Review docs / post PR suggestions | references/reviewing-docs.md |
The authoring workflow in references/writing-docs.md ties these together: gather context → locate where the page belongs → pick a content type → draft against the style guide → choose components for each piece of data → validate.
Validate before you finish
Run validation after any content change. Match the command set to your environment — a full build is local-only.
pnpm run check # Type-check: validates frontmatter schemas + Astro types
pnpm run build # Full build: validates MDX parsing, image paths, internal links — LOCAL ONLY (times out in CI)
pnpm run format # Auto-fix Prettier formatting on edited files
In CI (CI=true), skip pnpm run build; run pnpm run check, pnpm run lint, and pnpm run format:core:check only.
If you modified public/__redirects, also run:
pnpm exec tsm bin/validate-redirects.ts
Always run pnpm run format on files you touched — CI fails on unformatted content.