Przejdź do treści
Biblioteka skilli
Programowanie · Pisanie

docs-write

/docs-write

Pisze dokumentację w stylu Metabase: rozmownym, jasnym i skupionym na użytkowniku, przy tworzeniu i edycji plików markdown i MDX.

Repozytorium
Vibe-Skills ↗
Licencja
Apache-2.0
Ostatnia zmiana repozytorium
25.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 25.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Pisze dokumentację w stylu Metabase: rozmownym, jasnym i skupionym na użytkowniku, przy tworzeniu i edycji plików markdown i MDX.

Oryginalny opis (EN)

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

Jak działa

  1. When writing documentation
Sekcje z nagłówków SKILL.md, w oryginale · 92 linii, 386 słów
Podgląd SKILL.md
---
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:**

```markdown
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](link)" ✅
- "Read the docs [here](link)" ❌

### 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](link) | Click [here](link) |

Wersje

RepozytoriumWynikLicencja
Ta strona · foryourhealth111-pixel/Vibe-Skills100Apache-2.0
mickeyyaya/evolve-loop100Apache-2.0
metabase/metabase100AGPL-3.0
nightgauge/nightgauge95Apache-2.0

Identyczna treść występuje jeszcze w 5 innych folderach na GitHubie. Tu pokazujemy jedną, najlepiej ocenioną kopię.

Migawka bazy z 28.10.2026 · wersja paczki fee660300b79 (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100technical-docs
    Pisze i recenzuje dokumentację techniczną SDK Sentry, zwłaszcza pliki MDX w docs/platforms.
  • 100docs-review
    Przegląda zmiany w dokumentacji pod kątem zgodności z przewodnikiem stylu pisania Metabase, w pull requestach, plikach i diffach z plikami markdown.
  • 100writing-docs
    Pomaga pisać i edytować dokumentację Remotion: dodawanie stron, edycja plików MDX w packages/docs i tworzenie treści.
  • 100writing-docs
    Pomaga pisać i edytować dokumentację Remotion: dodawanie stron, edycja plików MDX w packages/docs i tworzenie treści.
  • 100writing-docs
    Pomaga pisać i edytować dokumentację Remotion: dodawanie stron, edycja plików MDX w packages/docs i tworzenie treści.
  • 90write-docs
    Pisze i przerabia dokumentację QUI Docs w plikach MDX: strony, nawigację, linki, przykłady i materiały graficzne przed pull requestem.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.