Good docs writing
Write docs the way Modal writes them: direct, friendly, confident, and ruthlessly practical. Explain the why in one breath, then show working code. Treat the reader as a capable developer who wants to ship, not a student who needs a lecture.
Read references/style-guide.md for the full rule set (Voice, Structure, Terminology, Punctuation, Code examples, Formatting) and apply every rule while drafting.
The rules that matter most, before you open the reference:
- Address the reader as "you", never "the user" or "one".
- Open with the concept or benefit in the first sentence. No throat-clearing.
- Put a minimal runnable example near the top, then explain what just happened.
- Remove every em-dash. Use a period, comma, colon, or parentheses instead.
- Cut vague intensifiers ("seamlessly", "powerful", "robust", "cutting-edge"). Show a thing being easy instead of calling it easy.
- Backtick every code identifier, command, parameter, path, and filename.
To review existing prose against these rules instead of drafting, use good-docs-audit.
1---2name: good-docs-writing3description: Writing style guide derived from Modal's documentation voice. Apply when writing or editing docs, guides, tutorials, or technical prose that should read direct, second-person, confident, low-jargon, and example-first. Use to draft new docs in this voice or to revise existing prose toward it.4---5
6# Good docs writing
7
8Write docs the way Modal writes them: direct, friendly, confident, and ruthlessly practical. Explain the _why_ in one breath, then show working code. Treat the reader as a capable developer who wants to ship, not a student who needs a lecture.
9
10Read `references/style-guide.md` for the full rule set (Voice, Structure, Terminology, Punctuation, Code examples, Formatting) and apply every rule while drafting.
11
12The rules that matter most, before you open the reference:
13
14- Address the reader as "you", never "the user" or "one".
15- Open with the concept or benefit in the first sentence. No throat-clearing.
16- Put a minimal runnable example near the top, then explain what just happened.
17- Remove every em-dash. Use a period, comma, colon, or parentheses instead.
18- Cut vague intensifiers ("seamlessly", "powerful", "robust", "cutting-edge"). Show a thing being easy instead of calling it easy.
19- Backtick every code identifier, command, parameter, path, and filename.
20
21To review existing prose against these rules instead of drafting, use `good-docs-audit`.
Composio HQ