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.
Recherche de documentation projet
Documentation
Trouve rapidement des informations dans le dossier docs/ d'un projet : état, procédures, stratégies et références.