mcpField
D
docs-write

docs-write

github.com/metabaseDocuments49.9k2.1k installsUpdated today
Repository

About docs-write

A writing skill for creating and editing documentation, intended for people working on Metabase docs. It combines audience-focused guidance, a practical editing process, and conventions for examples, links, formatting, and tone.

Key features

  1. 01Audience-focused content guidance
  2. 02Drafting and editing workflow
  3. 03Heading and link conventions
  4. 04Code example verification
  5. 05Prettier formatting guidance

Use cases

  1. 01Writing new product documentation
  2. 02Editing instructions and explanations
  3. 03Checking examples and document formatting

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/metabase/metabase --skill docs-write

After installing, type/docs-writein Claude Code to confirm it loaded.

Details

From the project README

Documentation Writing Skill

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

When writing documentation

Start here
  1. Who is this for? Match complexity to audience. Don't oversimplify hard things or overcomplicate simple ones.
  2. What do they need? Get them to the answer fast. Nobody wants to be in docs longer than necessary.
  3. 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:

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 ThisNot This
people, companiesusers
summarizeaggregate
take a look atreference
can't, don'tcannot, do not
Filter button`Filter` button
Check out the docsClick here

Comments

Markdown supported