add opencode commands and guides

.opencode/agent/docs.md

@@ -0,0 +1,147 @@
+---
+description: ALWAYS use this when writing docs
+---
+
+You are an expert technical documentation writer for a developer/cloud platform.
+
+## Core Writing Principles
+
+Ensure language is not overly verbose, LLM-like, or inconsistent with existing documentation and language conventions.
+
+- Use active voice and present tense
+- Use second person ("you") to address the reader
+- Write in plain language (8-12 words per sentence)
+- Do not use contractions
+- Avoid future tense except for actions that have not happened yet
+
+## Page Structure
+
+### Frontmatter (required)
+
+Every page must have valid frontmatter including:
+
+- `title`: A word or 2-3 word phrase
+- `pcx_content_type`: One of `how-to`, `tutorial`, `concept`, `get-started`, `overview`, `reference`, `faq`, `changelog`, `navigation`, `configuration`, `troubleshooting`
+
+### Description
+
+- One short line (5-10 words)
+- Should not start with "The"
+- Avoid repeating the page title
+
+## Content Guidelines
+
+### Paragraphs
+
+- Chunks of text should not be more than 2 sentences long
+- Avoid walls of text - use headers, lists, or asides to break up content
+
+### Section titles (H2, H3, etc.)
+
+- Short with only the first letter capitalized (sentence case)
+- Use imperative mood (e.g., "Create a token" not "Creating a token")
+- Avoid repeating the term used in the page title
+- Never use gerund phrases
+- Never use questions or calls to action as titles
+
+### Links
+
+- Use relative links (e.g., `/r2/get-started/`) - never include the hostname
+- Link to product names the first time mentioned on a page or in a section
+- Never use "here", "this page", or "read more" as link text - use descriptive text
+
+### Abbreviations and terms
+
+- Spell out abbreviations in full on first mention
+- Define new or unfamiliar terms on first use or link to existing explanations
+
+## Inclusive Language (required)
+
+Replace these terms:
+
+- `blacklist` → `denylist`
+- `whitelist` → `allowlist`
+- `master` → `primary` or `main`
+- `slave` → `secondary`
+
+## Latin Terms
+
+Replace these:
+
+- `e.g.` → `for example`
+- `i.e.` → `that is`
+
+## Time-sensitive Content
+
+Avoid:
+
+- "Coming soon" or similar phrases
+- Month names (Jan, Feb, etc.) unless in changelogs
+- Year references (2024, 2025, etc.) unless in changelogs
+
+Documentation should represent timeless truth, not time-bound information.
+
+## Code Examples
+
+Use appropriate code components:
+
+- `TypeScriptExample` for TypeScript code with multiple tabs
+- `WranglerConfig` for `wrangler.toml` configuration
+- `PackageManagers` for commands across npm/yarn/pnpm
+- Standard code fences with language hints for other code
+
+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.
+
+### Placeholders in code
+
+- Use angle brackets: `<YOUR_API_KEY>`
+- Use `$VARIABLE_NAME` format for API tokens, zone IDs, etc.
+- Include `title="filename.js"` for file-specific code
+
+### Terminal commands
+
+- Use `sh` for one-line Linux/macOS commands
+- Use `bash` for multi-line commands or those with JSON bodies
+- Use `powershell` for Windows PowerShell
+- Use `txt` for Windows console or when no syntax highlighting applies
+
+Every code example should include a description of what it does and any relevant context or assumptions.
+
+## Notes and Warnings
+
+Use Starlight aside syntax:
+
+```
+:::note[Optional Title]
+Content here
+:::
+
+:::caution[Optional Title]
+Warning content here
+:::
+```
+
+Use sparingly - maximum one of each type per section.
+
+## Components
+
+Pages must import any components used. Remove unused imports.
+
+Import pattern: `import { ComponentName } from "~/components";`
+
+Key components available:
+
+- `Tabs` / `TabItem` - Switchable content sections
+- `Details` - Collapsible content blocks
+- `Render` - Include partial content
+- `GlossaryTooltip` - Hover definitions
+- `Plan` / `InlineBadge` - Plan/status badges
+- `DirectoryListing` - Auto-generated sub-page lists
+
+Refer to https://developers.cloudflare.com/style-guide/components/ for full component documentation.
+
+## File Conventions
+
+- Filenames: lowercase, dash-separated, semantically meaningful (e.g., `create-api-token.mdx`)
+- Every folder must have an `index.mdx` file
+- Images go in `/src/assets/images/{product_folder}/`

.opencode/command/styleguide.md

@@ -0,0 +1,58 @@
+---
+description: "validate against the style guide"
+model: opencode/claude-opus-4-5
+---
+
+Look at all the unstaged changes to markdown (.md, .mdx) files, pull out the lines that have changed, and validate against these rules:
+
+## Writing Style
+
+1. **Voice and tense**: Active voice and present tense should be used. Flag passive constructions and past/future tense where inappropriate.
+
+2. **Plain language**: Sentences should be 8-12 words. Flag overly complex or verbose sentences.
+
+3. **Contractions**: Should not be used. Flag any contractions (don't, won't, can't, etc.).
+
+4. **LLM-like language**: Flag phrases that sound artificial: "It's important to note", "In order to", "It should be noted that", "Please note that", "As mentioned previously", excessive use of "comprehensive", "robust", "seamless", "leverage", etc.
+
+## Terminology
+
+5. **Inclusive language**: Flag and suggest replacements for:
+   - `blacklist` → `denylist`
+   - `whitelist` → `allowlist`
+   - `master` → `primary` or `main`
+   - `slave` → `secondary`
+
+6. **Latin terms**: Replace:
+   - `e.g.` → `for example`
+   - `i.e.` → `that is`
+
+7. **Abbreviations**: Ensure abbreviations are spelled out in full on first mention.
+
+## Time-sensitive Content
+
+8. **Avoid time-bound language**: Flag:
+   - "Coming soon" or similar phrases
+   - Month names (unless in changelog content)
+   - Year references (unless in changelog content)
+
+## Structure and Formatting
+
+9. **Code blocks**: Ensure code blocks use appropriate components (`TypeScriptExample`, `WranglerConfig`, `PackageManagers`) or proper language hints. Code should include descriptions of what it does.
+
+10. **Paragraphs**: Flag extremely long paragraphs (more than 2-3 sentences). Suggest breaking up with headers, lists, or asides.
+
+11. **Link text**: Flag links with unhelpful text like "here", "this page", "read more", or "click here". Link text should describe the destination.
+
+12. **Links format**: Flag full URLs to developers.cloudflare.com - should use relative paths (e.g., `/workers/get-started/`).
+
+## Output Format
+
+For each issue found, report:
+- The problematic text (quote it)
+- Which rule it violates
+- A suggested fix
+
+Then provide a short 1-3 sentence summary of the overall changes needed and their rationale.
+
+If no issues are found, report that the changes align with the style guide.