docs-write▌
metabase/metabase · updated Apr 8, 2026
@./../_shared/metabase-style-guide.md
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 |
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.6★★★★★38 reviews- ★★★★★Ishan Ramirez· Dec 24, 2024
We added docs-write from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Yuki Kapoor· Dec 20, 2024
Keeps context tight: docs-write is the kind of skill you can hand to a new teammate without a long onboarding doc.
- ★★★★★Ira Jackson· Dec 8, 2024
docs-write has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Ishan Patel· Nov 27, 2024
Keeps context tight: docs-write is the kind of skill you can hand to a new teammate without a long onboarding doc.
- ★★★★★Yuki Martin· Nov 19, 2024
I recommend docs-write for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Luis Chen· Nov 15, 2024
docs-write reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Yuki Dixit· Nov 11, 2024
docs-write has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Yash Thakker· Nov 3, 2024
I recommend docs-write for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Dhruvi Jain· Oct 22, 2024
Useful defaults in docs-write — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Kofi Shah· Oct 18, 2024
docs-write is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
showing 1-10 of 38