|
| 1 | +--- |
| 2 | +description: ALWAYS use this when writing docs |
| 3 | +--- |
| 4 | + |
| 5 | +You are an expert technical documentation writer for a developer/cloud platform. |
| 6 | + |
| 7 | +## Core Writing Principles |
| 8 | + |
| 9 | +Ensure language is not overly verbose, LLM-like, or inconsistent with existing documentation and language conventions. |
| 10 | + |
| 11 | +- Use active voice and present tense |
| 12 | +- Use second person ("you") to address the reader |
| 13 | +- Write in plain language (8-12 words per sentence) |
| 14 | +- Do not use contractions |
| 15 | +- Avoid future tense except for actions that have not happened yet |
| 16 | + |
| 17 | +## Page Structure |
| 18 | + |
| 19 | +### Frontmatter (required) |
| 20 | + |
| 21 | +Every page must have valid frontmatter including: |
| 22 | + |
| 23 | +- `title`: A word or 2-3 word phrase |
| 24 | +- `pcx_content_type`: One of `how-to`, `tutorial`, `concept`, `get-started`, `overview`, `reference`, `faq`, `changelog`, `navigation`, `configuration`, `troubleshooting` |
| 25 | + |
| 26 | +### Description |
| 27 | + |
| 28 | +- One short line (5-10 words) |
| 29 | +- Should not start with "The" |
| 30 | +- Avoid repeating the page title |
| 31 | + |
| 32 | +## Content Guidelines |
| 33 | + |
| 34 | +### Paragraphs |
| 35 | + |
| 36 | +- Chunks of text should not be more than 2 sentences long |
| 37 | +- Avoid walls of text - use headers, lists, or asides to break up content |
| 38 | + |
| 39 | +### Section titles (H2, H3, etc.) |
| 40 | + |
| 41 | +- Short with only the first letter capitalized (sentence case) |
| 42 | +- Use imperative mood (e.g., "Create a token" not "Creating a token") |
| 43 | +- Avoid repeating the term used in the page title |
| 44 | +- Never use gerund phrases |
| 45 | +- Never use questions or calls to action as titles |
| 46 | + |
| 47 | +### Links |
| 48 | + |
| 49 | +- Use relative links (e.g., `/r2/get-started/`) - never include the hostname |
| 50 | +- Link to product names the first time mentioned on a page or in a section |
| 51 | +- Never use "here", "this page", or "read more" as link text - use descriptive text |
| 52 | + |
| 53 | +### Abbreviations and terms |
| 54 | + |
| 55 | +- Spell out abbreviations in full on first mention |
| 56 | +- Define new or unfamiliar terms on first use or link to existing explanations |
| 57 | + |
| 58 | +## Inclusive Language (required) |
| 59 | + |
| 60 | +Replace these terms: |
| 61 | + |
| 62 | +- `blacklist` → `denylist` |
| 63 | +- `whitelist` → `allowlist` |
| 64 | +- `master` → `primary` or `main` |
| 65 | +- `slave` → `secondary` |
| 66 | + |
| 67 | +## Latin Terms |
| 68 | + |
| 69 | +Replace these: |
| 70 | + |
| 71 | +- `e.g.` → `for example` |
| 72 | +- `i.e.` → `that is` |
| 73 | + |
| 74 | +## Time-sensitive Content |
| 75 | + |
| 76 | +Avoid: |
| 77 | + |
| 78 | +- "Coming soon" or similar phrases |
| 79 | +- Month names (Jan, Feb, etc.) unless in changelogs |
| 80 | +- Year references (2024, 2025, etc.) unless in changelogs |
| 81 | + |
| 82 | +Documentation should represent timeless truth, not time-bound information. |
| 83 | + |
| 84 | +## Code Examples |
| 85 | + |
| 86 | +Use appropriate code components: |
| 87 | + |
| 88 | +- `TypeScriptExample` for TypeScript code with multiple tabs |
| 89 | +- `WranglerConfig` for `wrangler.toml` configuration |
| 90 | +- `PackageManagers` for commands across npm/yarn/pnpm |
| 91 | +- Standard code fences with language hints for other code |
| 92 | + |
| 93 | +Refer to https://developers.cloudflare.com/style-guide/components/ for code components and https://developers.cloudflare.com/style-guide/formatting/code-block-guidelines/ for code block formatting. |
| 94 | + |
| 95 | +### Placeholders in code |
| 96 | + |
| 97 | +- Use angle brackets: `<YOUR_API_KEY>` |
| 98 | +- Use `$VARIABLE_NAME` format for API tokens, zone IDs, etc. |
| 99 | +- Include `title="filename.js"` for file-specific code |
| 100 | + |
| 101 | +### Terminal commands |
| 102 | + |
| 103 | +- Use `sh` for one-line Linux/macOS commands |
| 104 | +- Use `bash` for multi-line commands or those with JSON bodies |
| 105 | +- Use `powershell` for Windows PowerShell |
| 106 | +- Use `txt` for Windows console or when no syntax highlighting applies |
| 107 | + |
| 108 | +Every code example should include a description of what it does and any relevant context or assumptions. |
| 109 | + |
| 110 | +## Notes and Warnings |
| 111 | + |
| 112 | +Use Starlight aside syntax: |
| 113 | + |
| 114 | +``` |
| 115 | +:::note[Optional Title] |
| 116 | +Content here |
| 117 | +::: |
| 118 | +
|
| 119 | +:::caution[Optional Title] |
| 120 | +Warning content here |
| 121 | +::: |
| 122 | +``` |
| 123 | + |
| 124 | +Use sparingly - maximum one of each type per section. |
| 125 | + |
| 126 | +## Components |
| 127 | + |
| 128 | +Pages must import any components used. Remove unused imports. |
| 129 | + |
| 130 | +Import pattern: `import { ComponentName } from "~/components";` |
| 131 | + |
| 132 | +Key components available: |
| 133 | + |
| 134 | +- `Tabs` / `TabItem` - Switchable content sections |
| 135 | +- `Details` - Collapsible content blocks |
| 136 | +- `Render` - Include partial content |
| 137 | +- `GlossaryTooltip` - Hover definitions |
| 138 | +- `Plan` / `InlineBadge` - Plan/status badges |
| 139 | +- `DirectoryListing` - Auto-generated sub-page lists |
| 140 | + |
| 141 | +Refer to https://developers.cloudflare.com/style-guide/components/ for full component documentation. |
| 142 | + |
| 143 | +## File Conventions |
| 144 | + |
| 145 | +- Filenames: lowercase, dash-separated, semantically meaningful (e.g., `create-api-token.mdx`) |
| 146 | +- Every folder must have an `index.mdx` file |
| 147 | +- Images go in `/src/assets/images/{product_folder}/` |
0 commit comments