Notre avis
Rédige et modifie des documentations selon le guide de style conversationnel et centré utilisateur de Metabase.
Points forts
- Fournit des directives claires sur la structure, le ton et le format.
- Inclut des exemples concrets de bonnes et mauvaises pratiques.
- Encourage une relecture et une édition systématiques.
- Intègre des commandes de formatage spécifiques (Prettier).
Limites
- Spécifique au style de Metabase, donc pas universel.
- Dépend d'un fichier de guide de style externe.
- Ne remplace pas un jugement éditorial humain.
Lors de la création ou mise à jour de documentation utilisateur devant suivre le style Metabase.
Pour des commentaires de code internes ou des documentations techniques hors du contexte Metabase.
Analyse de sécurité
PrudenceThe skill is documentation-focused and does not instruct destructive, exfiltrating, or obfuscated actions. The use of Bash is limited to formatting and is legitimate, so caution is appropriate due to the presence of a command execution capability.
- •The skill declares Bash as an allowed tool and instructs running `bun run prettier --write <file-path>`, which executes code but is a standard formatting command.
Exemples
Write a new documentation page for the 'Custom Expressions' feature in Metabase, following the docs-write skill and the Metabase style guide.Edit this guide to match Metabase's style: make headings imperative, use active voice, and remove vague links. Use the docs-write skill.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 |
Generateur de Documentation API
Documentation
Genere automatiquement de la documentation API OpenAPI/Swagger.
Rédacteur Technique
Documentation
Rédige de la documentation technique claire selon les meilleurs style guides.
Embellir les README GitHub
Documentation
Redessiner les pages d'accueil des README GitHub ou créer des actifs SVG purs, hybrides PNG/WebP composés en SVG et GIF animés optionnels.