/docs-style

name: docs-style
description: Core technical documentation writing principles for voice, tone, structure, and LLM-friendly patterns. Use when writing or reviewing any documentation.
user-invocable: false

Documentation Style Guide

Apply these principles when writing or reviewing documentation to ensure clarity, consistency, and accessibility for both human readers and LLMs.

Choose the Right Documentation Type First

Style serves a purpose, and the purpose depends on which of the four Diataxis types you are writing. Before applying the conventions below, decide whether the document is a **Tutorial** (learning), **How-To guide** (a task), **Reference** (looking up), or **Explanation** (understanding) — these are not interchangeable, and mixing them in one document weakens all of them.

To choose, ask the two compass questions: *action or cognition? acquisition or application?*

| The reader's stance | Type | |---|---| | "I'm learning — guide my hands" | **Tutorial** | | "I have a goal — help me reach it" | **How-To** | | "I'm working — let me look something up" | **Reference** | | "I'm reflecting — help me understand why" | **Explanation** |

For the full decision procedure, the 2×2 map, the two distinctions that resolve most ambiguity (Tutorial vs. How-To, Reference vs. Explanation), and the quality model, see [references/diataxis-compass.md](references/diataxis-compass.md). The type-specific skills (`tutorial-docs`, `howto-docs`, `reference-docs`, `explanation-docs`) build on the principles in this guide once the type is chosen.

Voice and Tone

Use Second Person

Address the reader directly as "you" rather than "the user" or "developers."

<!-- Good -->
You can configure the API by setting environment variables.

<!-- Avoid -->
The user can configure the API by setting environment variables.
Developers should configure the API by setting environment variables.

Prefer Active Voice

Write sentences where the subject performs the action. Active voice is clearer and more direct.

<!-- Good -->
Create a configuration file in the root directory.
The function returns an array of user objects.

<!-- Avoid -->
A configuration file should be created in the root directory.
An array of user objects is returned by the function.

Be Concise

Cut unnecessary words. Every word should earn its place.

<!-- Good -->
Run the install command.

<!-- Avoid -->
In order to proceed, you will need to run the install command.

<!-- Good -->
This endpoint returns user data.

<!-- Avoid -->
This endpoint is used for the purpose of returning user data.

Common phrases to simplify:

| Instead of | Use | |------------|-----| | in order to | to | | for the purpose of | to, for | | in the event that | if | | at this point in time | now | | due to the fact that | because | | it is necessary to | you must | | is able to | can | | make use of | use |

Document Structure

Write Clear, Descriptive Headings

Headings should tell readers exactly what the section contains. Avoid clever or vague titles.

<!-- Good -->
## Install the CLI
## Configure Authentication
## Handle Rate Limits

<!-- Avoid -->
## Getting Started (vague)
## The Fun Part (clever)
## Misc (uninformative)

Create Self-Contained Pages

Assume readers may land on any page directly from search. Each page should:

• Explain what the feature/concept is
• State prerequisites clearly
• Provide complete context for the topic

<!-- Good: Self-contained -->
# Webhooks

Webhooks let you receive real-time notifications when events occur in your account.

## Prerequisites

- An active API key with webhook permissions
- A publicly accessible HTTPS endpoint

## Create a Webhook

...

Use Semantic Markup

Choose the right format for the content type:

• **Headings**: Follow proper hierarchy (h1 > h2 > h3, never skip levels)
• **Lists**: Use for multiple related items
• **Tables**: Use for structured data with consistent attributes
• **Code blocks**: Use for any code, commands, or file paths

<!-- Good: Table for structured data -->
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| api_key | string | Yes | Your API key |
| timeout | integer | No | Request timeout in seconds |

<!-- Good: List for steps or options -->
To authenticate, you can:
- Use an API key in the header
- Use OAuth 2.0
- Use a service account

Make Content Skimmable

Break dense paragraphs into digestible chunks:

• Keep paragraphs to 3-4 sentences maximum
• Use bullet points for lists of items
• Add subheadings to long sections
• Put key information first (inverted pyramid)

<!-- Good: Skimmable -->
## Error Handling

The API returns standard HTTP status codes.

### Common Errors

- **400 Bad Request**: Invalid parameters. Check the request body.
- **401 Unauthorized**: Invalid or missing API key.
- **429 Too Many Requests**: Rate limit exceeded. Wait and retry.

### Retry Strategy

For 429 errors, use exponential backoff starting at 1 second.

Consistency

Use One Term Per Concept

Pick a term and use it consistently. Switching terms confuses readers.

<!-- Good: Consistent terminology -->
Generate an API key in the dashboard. Use your API key in the Authorization header.

<!-- Avoid: Inconsistent terminology -->
Generate an API key in the dashboard. Use your API token in the Authorization header.

Document your terminology choices:

| Concept | Use | Don't use | |---------|-----|-----------| | Authentication credential | API key | API token, secret key, access key | | Configuration file | config file | settings file, preferences file | | Command line | CLI | terminal, command prompt, shell |

Apply Consistent Formatting

Use the same formatting for similar content types:

• **UI elements**: Bold (Click **Save**)
• **Code/commands**: Backticks (`npm install`