Move changelog command to agent skill

.agents/skills/changelog/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: changelog
+description: Creates, updates, and reviews product changelog entries for the Cloudflare documentation site. Load when generating changelog MDX files, editing existing entries, reviewing changelog style, or validating frontmatter.
+---
+
+Use this skill when creating, editing, or reviewing changelog entries under `src/content/changelog/`.
+
+## Prerequisites
+
+You need three things before writing:
+
+1. A **product name** (for example, Workers, KV, Hyperdrive, Containers, R2)
+2. A **description of the change** being documented
+3. Enough context to explain the "why" and use cases
+
+If any are missing, ask for clarification. Do not proceed without all three.
+
+## Determine the product folder
+
+Use the product name to find the correct folder under `src/content/changelog/{product}/`. Check existing folders for valid product names — do not guess.
+
+## Create the changelog file
+
+Path format:
+
+```
+src/content/changelog/{product}/{YYYY-MM-DD}-{useful-short-name}.mdx
+```
+
+Use today's date and a concise, hyphenated slug describing the change.
+
+## Frontmatter
+
+```yaml
+---
+title: <TITLE>
+description: <ONE_SENTENCE_SUMMARY>
+products:
+  - <PRODUCT>
+date: <YYYY-MM-DD>
+---
+```
+
+## Writing style
+
+- Imperative mood, active voice
+- Opening sentence: what the feature/change is and what problem it solves
+- Expand on usage, use cases, and the "why" in subsequent paragraphs
+- Assume a technical developer/cloud audience
+- Keep sentences concise (8-12 words where possible)
+- Do not use contractions
+- Do not use LLM-like phrases ("It's important to note", "leverage", "seamless", etc.)
+- Replace `e.g.` with "for example" and `i.e.` with "that is"
+
+## Code examples
+
+Include a code example when the changelog describes an API, SDK, or configuration change.
+
+- Include a code block demonstrating usage of the new feature
+- Use plain JavaScript/TypeScript code blocks (`js` or `ts`)
+- Use `jsonc` for wrangler.json config
+- Keep snippets short and focused on the new feature
+- Minimize boilerplate
+- Add imports if using components: `import { Render, TypeScriptExample, WranglerConfig } from "~/components";`
+
+## Documentation links
+
+End the changelog with a link to relevant documentation:
+
+- Use relative paths (for example, `/workers/configuration/placement/`)
+- Link text must describe the destination — never "click here" or "read more"
+- Check for uncommitted/staged `.md`/`.mdx` files that might be the related documentation
+
+## Reference examples
+
+Review these existing changelogs for style and format guidance:
+
+- `src/content/changelog/workers/` - Workers changelogs with code examples
+- `src/content/changelog/kv/` - KV changelogs
+- `src/content/changelog/hyperdrive/` - Hyperdrive changelogs
+- `src/content/changelog/containers/` - Container changelogs
+
+Read 2-3 entries from the target product's changelog folder before writing to match style and depth. If the target folder has fewer than 2 entries, read from the folders listed above as a reference.
+
+## Editing existing entries
+
+When updating an existing changelog entry, preserve the original structure and voice. Apply only the requested changes — do not rewrite surrounding content.
+
+## Reviewing changelog entries
+
+When reviewing, validate against every section above: frontmatter fields, file path conventions, writing style, code example quality, and documentation links. Flag issues by severity:
+
+- **Error**: Missing required frontmatter fields, wrong product folder, broken links
+- **Warning**: Style violations, missing code examples for API changes, vague descriptions
+- **Nit**: Minor phrasing improvements
+
+## Output
+
+Create or update the changelog file and show the complete file path and content.

.opencode/command/changelog.md

@@ -1,73 +1,12 @@
 ---
 description: Generate a product changelog entry
+agent: docs
 ---
 
-Generate a changelog entry for the Cloudflare documentation site based on the user's request.
+Load the `changelog` skill and follow its instructions to generate a changelog entry.
 
-## User Request
+Request: $ARGUMENTS
 
-$ARGUMENTS
-
-## Instructions
-
-1. **Validate the request**: Ensure the user has provided:
-   - A clear product name (for example, Workers, KV, Hyperdrive, Containers, R2, etc.)
-   - A description of the change or feature being documented
-   - Enough context to explain the "why" and use-cases
-
-   If any of these are missing or unclear, ask the user for clarification before proceeding.
-
-2. **Determine the product folder**: Use the product name to identify the correct changelog folder under `src/content/changelog/{product}/`. Refer to existing folders for valid product names.
-
-3. **Create the changelog file**: Create a new file at:
-   ```
-   src/content/changelog/{product}/{YYYY-MM-DD}-{useful-short-name}.mdx
-   ```
-   Use today's date and a concise, hyphenated slug describing the change.
-
-4. **Frontmatter format**:
-   ```yaml
-   ---
-   title: {Concise title describing the change}
-   description: {One-sentence summary of what changed and why it matters}
-   products:
-     - {product}
-   date: {YYYY-MM-DD}
-   ---
-   ```
-
-5. **Writing style guidelines**:
-   - Use imperative mood and active voice
-   - The opening sentence must clearly explain what the new feature/change is and what problem it solves
-   - Expand on usage, use-cases, and the "why" in subsequent paragraphs
-   - Assume a technical developer/cloud audience
-   - Keep sentences concise (8-12 words where possible)
-   - Avoid contractions
-   - Avoid LLM-like phrases ("It's important to note", "leverage", "seamless", etc.)
-   - Replace `e.g.` with "for example" and `i.e.` with "that is"
-
-6. **Code examples for Developer Platform products**:
-   For products in the Developer Platform group (Workers, Durable Objects, Pipelines, KV, Hyperdrive, R2, D1, Queues, Containers, etc.):
-   - Include a code block demonstrating usage of the new feature
-   - Use plain JavaScript/TypeScript code blocks (```js or ```ts)
-   - If showing wrangler.json config, use ```jsonc
-   - Keep code snippets short and focused on the new feature
-   - Minimize boilerplate and unnecessary code
-   - Add imports at the top if using components: `import { Render, TypeScriptExample, WranglerConfig } from "~/components";`
-
-7. **Documentation links**: End the changelog with a link to relevant documentation:
-   - Use relative paths (for example, `/workers/configuration/placement/`)
-   - Link text should describe the destination, not "click here" or "read more"
-   - Check for any uncommitted/staged .md/.mdx files that might be the related documentation
-
-## Reference Examples
-
-Review these existing changelogs for style and format guidance:
-- `src/content/changelog/workers/` - Workers changelogs with code examples
-- `src/content/changelog/kv/` - KV changelogs
-- `src/content/changelog/hyperdrive/` - Hyperdrive changelogs
-- `src/content/changelog/containers/` - Container changelogs
-
-## Output
-
-Create the changelog file and show the user the complete file path and content.
+If no product or description is provided, check for staged or uncommitted `.mdx` files
+to infer context. If still unclear, ask for clarification. Read 2-3 existing entries in
+the target product's changelog folder before writing.