// Write and review Radix platform documentation. Use when: writing docs, editing docs, reviewing docs, creating guides, updating documentation pages, fixing doc style, proofreading, documentation review.
Write Radix platform notification messages for Slack. Use when: writing announcements, deprecation notices, action-needed alerts, maintenance windows, or breaking changes for Radix users.
Update AGENTS.md when skills are added, removed, or modified. Use when: creating a new skill, deleting a skill, renaming a skill, updating a skill description, syncing AGENTS.md with current skills.
| name | radix-docs |
| description | Write and review Radix platform documentation. Use when: writing docs, editing docs, reviewing docs, creating guides, updating documentation pages, fixing doc style, proofreading, documentation review. |
| argument-hint | Describe what documentation to write or review |
Focus exclusively on Radix platform usage and configuration. Do not include Equinor-specific internal policies, rules, organizational details, or proprietary configuration. The audience is any developer using the open-source Radix platform.
Documentation files use Docusaurus with YAML frontmatter:
---
title: Page Title
displayed_sidebar: sidebarName
---
Use a single # Heading per file matching the frontmatter title. Organize content with ## and ### subheadings.
:::tip, :::warning, :::info blocks for callouts.md extensions — [text](../path/to/file.md) or with anchors [text](../path/to/file.md#section)Write in a professional but conversational tone, as if speaking to a fellow developer. Be direct and confident without being pushy. Use American English spelling throughout (e.g., "customize" not "customise", "color" not "colour").
Use contractions naturally — it's, you're, we're, don't. Avoid overly formal or generic language. The reader should feel guided, not lectured.
Use active voice instead of passive voice. Vary sentence length and structure for a natural flow. Choose specific, concrete words over vague terms. Replace repetitive phrases with varied alternatives.
Good: "Radix rebuilds your component when you push to the branch." Avoid: "The component is rebuilt by Radix when a push is made to the branch."
Prefer flowing paragraphs over bullet points. Use bullet points only when listing discrete items (config options, CLI flags, steps in a procedure) and keep them parallel in structure. If a list has only two items, write it as a sentence instead.
Open each section with the most important information. Don't bury the key point after three sentences of context. End sections with clear next steps or a conclusion when appropriate.
Don't repeat information that already appears in another section of the same page or in a linked page. Cross-reference with links instead.
## **Heading**)<br/> for self-closing HTML tags, not <br>**Title**<br/> not **Title**:<br/>replicas), file names (radixconfig.yaml), commands (rx create), and environment variables (RADIX_APP)When reviewing, watch for and correct these patterns:
| Instead of | Write |
|---|---|
| "This creates:" | "This leads to:" |
| "Key Benefits:" | "Benefits include:" |
| Passive voice | Active voice |
| Long bullet-point lists explaining concepts | Flowing paragraphs |
| Generic statements | Specific, actionable content |
| British spelling (organisation, colour) | American spelling (organization, color) |
When reviewing documentation, verify:
radixconfig.yaml configuration.md extensions