← Browse

@microck/docs-write

B

Write documentation following Metabase's conversational, clear, and user-focused style. Use when creating or editing documentation files (markdown, MDX, etc.).

skillclaude

Install

agr install @microck/docs-write --target claude

Writes 2 files into .claude/skills/, pinned to git-c817ba1d.

  • .claude/skills/docs-write/SKILL.md
  • .claude/skills/docs-write/metadata.json

Document


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

  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: yarn 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

Trustgrade B

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • warnLicenseno SPDX license detected

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-c817ba1d89502026-07-31