Documentation Writer for Storyblok Ecosystem
Provide writing guidance for Storyblok DX documentation.
When to use
Use this skill for the following tasks:
- Create or edit documentation pages and
README.md files.
- Ensure a consistent writing style across all content.
Voice and Perspective
- Active Voice: Always use the active voice. Avoid the passive voice.
- Imperative Mood: Use the imperative second-person voice for instructions ("Add the following...").
- Third-person: Use the third-person voice for descriptions and technical references.
- Generic Voice: Strive for simplicity, clarity, and consistency. Avoid soloists; the documentation should feel written by one team.
- Gerunds: Avoid gerunds (nouns ending in "-ing") in headings and instructions. Use "Find information" instead of "Finding information."
- Exception: Gerunds are acceptable when referring to established technical concepts (for example, "Caching," "Routing," or "Versioning").
Active voice
Subject performs action. Prefer this.
| Active (use) |
Passive (avoid) |
| The module creates a connection |
A connection is created by the module |
| You can override defaults |
Defaults can be overridden |
When passive is okay
- Actor unknown: "The file is loaded during startup."
- Object more important: "Data is cached for 5 minutes."
- System behavior: "Routes are generated from pages directory."
Spelling and Capitalization
Spelling
- American English: Use standard American spellings (for example, neighbor, center).
- Abbreviations: Define on first reference if used more than twice (for example, "universal resource identifier (URI)"). Use abbreviations for common terms (for example, "HTTP").
- Special Characters: Use only when technically correct. Avoid emojis and decorative symbols unless they add technical value.
Capitalization
- Title Case: Use Title Case for H1/Titles (
#) and CTAs.
- Sentence Case: Use sentence case for headings H2 through H6.
- Important: if there is no H1 assume that you're only see part of the document and always stick to casing rules!
- Technical Casing: Always use the technical casing for code, variables, and instances (for example,
pop(), StoryblokBridge vs storyblokBridge).
- File Types: Use uppercase (for example, JPEG, ZIP).
- URLs: Use lowercase.
- Lists: Capitalize list items.
- Colons: Use lowercase after a colon unless it's a proper noun or start of a full sentence.
Punctuation
- Oxford Comma: Always use a comma before the last item in a list.
- Dashes:
- Hyphens: Join compound phrases.
- Em dashes: Demarcate an aside, surrounded by spaces. Avoid En dashes.
- Spaces: Use only one space between sentences. No space before punctuation.
- Quotes: End punctuation goes inside the quotation mark ("like this.").
- Exception: Place punctuation outside quotation marks if the quote is a literal string, command, or code snippet to avoid syntax errors (for example, set the value to "true".).
- Parentheticals: End punctuation goes after the closing parenthesis unless the parenthetical is a full sentence.
Structure
- Headings:
- Only one H1 per page.
- Maintain semantic nesting (H3 under H2, H4 under H3).
- No single headings or sub-headings in a section.
- Lists:
- Default to unordered (bulleted) lists. Use ordered (numbered) only for essential sequences.
- Use parallel structure for list items.
- Parallels: Express coordinate ideas in similar form across lists, subheadings, and tables.
Subject-first declarative
Place subject first, verb follows. Clear and direct.
The `useStoryblokBridge` hook enables live preview.
The Storyblok CLI provides powerful migration tooling.
The debug option controls module behavior during development.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: document-writer3description: Use when writing documentation. Provides a writing style guide and content structure patterns.4---56# Documentation Writer for Storyblok Ecosystem78Provide writing guidance for Storyblok DX documentation.910## When to use1112Use this skill for the following tasks:1314- Create or edit documentation pages and `README.md` files.15- Ensure a consistent writing style across all content.1617## Voice and Perspective1819- **Active Voice**: Always use the active voice. Avoid the passive voice.20- **Imperative Mood**: Use the imperative second-person voice for instructions ("Add the following...").21- **Third-person**: Use the third-person voice for descriptions and technical references.22- **Generic Voice**: Strive for simplicity, clarity, and consistency. Avoid soloists; the documentation should feel written by one team.23- **Gerunds**: Avoid gerunds (nouns ending in "-ing") in headings and instructions. Use "Find information" instead of "Finding information."24 - **Exception**: Gerunds are acceptable when referring to established technical concepts (for example, "Caching," "Routing," or "Versioning").2526### Active voice2728Subject performs action. Prefer this.2930| Active (use) | Passive (avoid) |31| ------------------------------- | ------------------------------------- |32| The module creates a connection | A connection is created by the module |33| You can override defaults | Defaults can be overridden |3435### When passive is okay3637- Actor unknown: "The file is loaded during startup."38- Object more important: "Data is cached for 5 minutes."39- System behavior: "Routes are generated from pages directory."4041## Spelling and Capitalization4243### Spelling4445- **American English**: Use standard American spellings (for example, *neighbor*, *center*).46- **Abbreviations**: Define on first reference if used more than twice (for example, "universal resource identifier (URI)"). Use abbreviations for common terms (for example, "HTTP").47- **Special Characters**: Use only when technically correct. Avoid emojis and decorative symbols unless they add technical value.4849### Capitalization5051- **Title Case**: Use Title Case for H1/Titles (`#`) and CTAs.52- **Sentence Case**: Use sentence case for headings H2 through H6.53 - Important: if there is no H1 assume that you're only see part of the document and always stick to casing rules!54- **Technical Casing**: Always use the technical casing for code, variables, and instances (for example, `pop()`, `StoryblokBridge` vs `storyblokBridge`).55- **File Types**: Use uppercase (for example, JPEG, ZIP).56- **URLs**: Use lowercase.57- **Lists**: Capitalize list items.58- **Colons**: Use lowercase after a colon unless it's a proper noun or start of a full sentence.5960## Punctuation6162- **Oxford Comma**: Always use a comma before the last item in a list.63- **Dashes**: 64 - **Hyphens**: Join compound phrases.65 - **Em dashes**: Demarcate an aside, surrounded by spaces. Avoid En dashes.66- **Spaces**: Use only one space between sentences. No space before punctuation.67- **Quotes**: End punctuation goes inside the quotation mark ("like this.").68 - **Exception**: Place punctuation outside quotation marks if the quote is a literal string, command, or code snippet to avoid syntax errors (for example, set the value to "true".).69- **Parentheticals**: End punctuation goes after the closing parenthesis unless the parenthetical is a full sentence.7071## Structure7273- **Headings**:74 - Only one H1 per page.75 - Maintain semantic nesting (H3 under H2, H4 under H3).76 - No single headings or sub-headings in a section.77- **Lists**:78 - Default to unordered (bulleted) lists. Use ordered (numbered) only for essential sequences.79 - Use parallel structure for list items.80- **Parallels**: Express coordinate ideas in similar form across lists, subheadings, and tables.8182### Subject-first declarative8384Place subject first, verb follows. Clear and direct.8586```text87The `useStoryblokBridge` hook enables live preview.88The Storyblok CLI provides powerful migration tooling.89The debug option controls module behavior during development.90```9192---93> Converted and distributed by [TomeVault](https://tomevault.io/claim/storyblok) — claim your Tome and manage your conversions.94<!-- tomevault:4.0:skill_md:2026-04-11 -->