Skip to content

Commit 17a933b

Browse files
mnmkngclaude
andcommitted
docs: Add Claude Code writing style guide
Add .claude/rules/writing-style.md with documentation writing guidelines for AI assistants. Based on Apify style guide and TC-MO's technical writer feedback from PR #2185. Includes: - Core principles (simple, factual, technical) - Formatting rules (headings, bold, lists) - Grammar guidelines (articles, Oxford comma) - Terminology standards (Actor capitalization, word choice) - Common mistakes to avoid Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1 parent 2d88d90 commit 17a933b

1 file changed

Lines changed: 207 additions & 0 deletions

File tree

.claude/rules/writing-style.md

Lines changed: 207 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,207 @@
1+
# Apify Documentation Writing Style
2+
3+
Instructions for AI assistants writing Apify documentation. Based on Apify style guide and technical writer feedback.
4+
5+
## Core Principles
6+
7+
1. **Simple** - Get to the point. No sentence over 30 words. Every sentence delivers information.
8+
1. **Factual** - Back up claims with evidence. Use numbers, not vague qualifiers.
9+
1. **Technical** - Write for developers. Don't oversimplify. Link to fill knowledge gaps.
10+
11+
> Write the same way you would explain something to a person sitting next to you.
12+
13+
## Language & Tone
14+
15+
### US English
16+
17+
Use "analyze" not "analyse", "color" not "colour".
18+
19+
### Imperative tone
20+
21+
Use direct instructions, not soft recommendations:
22+
23+
| Avoid | Prefer |
24+
|-------|--------|
25+
| We recommend pinning the version | Pin the version |
26+
| You should use the latest SDK | Use the latest SDK |
27+
| It's best to avoid hardcoding | Avoid hardcoding |
28+
29+
### No sales language
30+
31+
| Avoid | Prefer |
32+
|-------|--------|
33+
| Experience Apify, the ultimate platform! | Welcome to Apify, the cloud web scraping platform. |
34+
| Our highly efficient system | Apify's system handles 500K requests per minute |
35+
36+
### Avoid first person
37+
38+
Use "you" to focus on the reader. Avoid "I", "me", "myself" in docs.
39+
40+
| Avoid | Prefer |
41+
|-------|--------|
42+
| I recommend using version 22 | Use version 22 |
43+
| In my experience, this works better | This approach is more reliable |
44+
45+
## Formatting
46+
47+
### Headings
48+
49+
**Sentence case only.** No title case.
50+
51+
| Avoid | Prefer |
52+
|-------|--------|
53+
| Store And Manage Data | Store and manage data |
54+
55+
**No gerunds (-ing forms).** Use noun phrases or imperatives.
56+
57+
| Avoid | Prefer |
58+
|-------|--------|
59+
| Finding available tags | Available tags |
60+
| Getting started with Actors | Get started with Actors |
61+
| Understanding the API | API overview |
62+
63+
Rationale: Noun-phrase headings are more scannable and search-friendly (Microsoft style guide).
64+
65+
### Bold
66+
67+
Use bold sparingly. Don't bold:
68+
- List introductions
69+
- Code block introductions
70+
- Section labels when context is clear
71+
72+
| Avoid | Prefer |
73+
|-------|--------|
74+
| **Examples:** | Examples: |
75+
| **In your Dockerfile**, use... | In your `Dockerfile`, use... |
76+
77+
Bold is for critical warnings or key terms, not routine structure.
78+
79+
### Ordered lists
80+
81+
Use `1.` for all items (not sequential numbers). Easier to maintain:
82+
83+
```markdown
84+
1. First step
85+
1. Second step
86+
1. Third step
87+
```
88+
89+
### Parallel structure
90+
91+
All items in a list must follow the same grammatical pattern:
92+
93+
```markdown
94+
# Avoid - mixed patterns
95+
1. Reproducibility - your builds behave the same
96+
1. Predictability - you know which version
97+
1. Easier to track down issues
98+
99+
# Prefer - consistent pattern
100+
1. Reproducibility - Your builds behave the same way
101+
1. Predictability - You know exactly which version you're running
102+
1. Debugging - Version-specific issues are easier to track down
103+
```
104+
105+
### Em dashes
106+
107+
**Don't use em dashes (—).** LLMs overuse them. Use hyphen with spaces ( - ) instead.
108+
109+
## Grammar
110+
111+
### Articles in definitions
112+
113+
Include "a/an" before nouns in definition lists:
114+
115+
| Avoid | Prefer |
116+
|-------|--------|
117+
| `{version}` - Node.js version only | `{version}` - A Node.js version only |
118+
119+
### Oxford comma
120+
121+
Always use the serial comma:
122+
123+
| Avoid | Prefer |
124+
|-------|--------|
125+
| pencil, eraser and notebook | pencil, eraser, and notebook |
126+
127+
### "the" before products
128+
129+
Use "the" before "Apify platform", "Apify SDK", etc.
130+
131+
| Avoid | Prefer |
132+
|-------|--------|
133+
| I use Apify platform | I use the Apify platform |
134+
135+
## Terminology
136+
137+
### Capitalization
138+
139+
- **Actor** - Always uppercase when referring to Apify Actors
140+
- **Apify Proxy**, **Apify Console**, **Apify Store** - Product names, capitalized
141+
- **the Apify platform** - Lowercase "platform", include "the"
142+
- **task**, **schedule** - Lowercase
143+
144+
### Word choice
145+
146+
| Word | When to use |
147+
|------|-------------|
148+
| legacy | Feature is deprecated or will be removed |
149+
| alternative | Valid approach, but not the preferred one |
150+
| deprecated | Feature will be removed in a future version |
151+
152+
## Links
153+
154+
### Action-oriented text
155+
156+
| Avoid | Prefer |
157+
|-------|--------|
158+
| [actor-node-playwright tags](url) | [View actor-node-playwright tags](url) |
159+
| See the [documentation](url) | [Read the documentation](url) |
160+
161+
### Trim filler words
162+
163+
| Avoid | Prefer |
164+
|-------|--------|
165+
| visit the Docker Hub tags page | visit Docker Hub |
166+
| check out the official docs | see the documentation |
167+
168+
### Actor references
169+
170+
First mention: Actor name with link, capitalized.
171+
172+
```markdown
173+
[Website Content Crawler](https://apify.com/apify/website-content-crawler)
174+
can crawl websites and extract text content.
175+
```
176+
177+
## Code Examples
178+
179+
- Use backticks for file names, commands, config keys
180+
- Prefer complete, runnable examples
181+
- Add comments only when code isn't self-explanatory
182+
- Match versions in examples (e.g., Dockerfile tag matches package.json version)
183+
184+
## Numbers & Formatting
185+
186+
- Thousands: comma separator ($1,000)
187+
- Decimals: period ($9.8)
188+
- Money: symbol before amount ($49, not 49$)
189+
- Dates: August 5, 2024 (never 5.8.2024)
190+
- Time: 5 pm or 5 PM (space after number)
191+
192+
## Common Mistakes
193+
194+
Patterns to avoid:
195+
- "Happy scraping!" closings
196+
- Em dashes
197+
- Title case headings
198+
- Gerunds in headings
199+
- Bold for routine structure
200+
- "Ok" (use "OK" or "okay")
201+
- Missing "the" before "Apify platform"
202+
- Sales language ("ultimate", "cutting-edge", "supercharge")
203+
- Vague claims without numbers
204+
205+
## Reference
206+
207+
Full Apify style guide: https://www.notion.so/apify/de9fbb99dcd84665b6d3f790fc88b3b6

0 commit comments

Comments
 (0)