Our review

Writes and edits documentation using Metabase's conversational, user-focused style guide.

Strengths

Clear guidance on structure, tone, and formatting.
Concrete examples of good and bad practices.
Encourages thorough review and editing process.
Integrates specific formatting commands (Prettier).

Limitations

Specific to Metabase's style, so not universal.
Relies on an external style guide file.
Not a substitute for human editorial judgment.

When to use it

When creating or updating user-facing documentation that should follow Metabase's style.

When not to use it

For internal code comments or highly technical reference documentation outside Metabase's context.

Examples

Draft a doc page

Write a new documentation page for the 'Custom Expressions' feature in Metabase, following the docs-write skill and the Metabase style guide.

Edit existing docs

Edit this guide to match Metabase's style: make headings imperative, use active voice, and remove vague links. Use the docs-write skill.

Audit documentation

Audit this file for common style mistakes per the docs-write skill: check for 'utilize', 'here' links, and non-conversational tone.

name: docs-write description: Write documentation following Metabase's conversational, clear, and user-focused style. Use when creating or editing documentation files (markdown, MDX, etc.). allowed-tools: Read, Write, Grep, Bash, Glob

Documentation Writing Skill

@./../_shared/metabase-style-guide.md

When writing documentation

Start here

Who is this for? Match complexity to audience. Don't oversimplify hard things or overcomplicate simple ones.
What do they need? Get them to the answer fast. Nobody wants to be in docs longer than necessary.
What did you struggle with? Those common questions you had when learning? Answer them (without literally including the question).

Writing process

Draft:

Write out the steps/explanation as you'd tell a colleague
Lead with what to do, then explain why
Use headings that state your point: "Set SAML before adding users" not "SAML configuration timing"

Edit:

Read aloud. Does it sound like you talking? If it's too formal, simplify.
Cut anything that doesn't directly help the reader
Check each paragraph has one clear purpose
Verify examples actually work (don't give examples that error)

Polish:

Make links descriptive (never "here")
Backticks only for code/variables, bold for UI elements
American spelling, serial commas
Keep images minimal and scoped tight

Format:

Run prettier on the file after making edits: bun run prettier --write <file-path>
This ensures consistent formatting across all documentation

Common patterns

Instructions:

Run:
\`\`\`
command-to-run
\`\`\`

Then:
\`\`\`
next-command
\`\`\`

This ensures you're getting the latest changes.

Not: "(remember to run X before Y...)" buried in a paragraph.

Headings:

"Use environment variables for configuration" ✅
"Environment variables" ❌ (too vague)
"How to use environment variables for configuration" ❌ (too wordy)

Links:

"Check out the SAML documentation" ✅
"Read the docs here" ❌

Watch out for

Describing tasks as "easy" (you don't know the reader's context)
Using "we" when talking about Metabase features (use "Metabase" or "it")
Formal language: "utilize", "reference", "offerings"
Too peppy: multiple exclamation points
Burying the action in explanation
Code examples that don't work
Numbers that will become outdated

Quick reference

| Write This | Not This | | -------------------------- | ------------------ | | people, companies | users | | summarize | aggregate | | take a look at | reference | | can't, don't | cannot, do not | | Filter button | `Filter` button | | Check out the docs | Click here |

Documentation Writing in Metabase Style

Recommended for