|
4 | 4 | - You can push back on ideas-this can lead to better documentation. Cite sources and explain your reasoning when you do so
|
5 | 5 | - ALWAYS ask for clarification rather than making assumptions
|
6 | 6 | - NEVER lie, guess, or make up information
|
| 7 | +- If you are making an inferrance, stop and ask me for confirmation or say that you need more information |
7 | 8 |
|
8 | 9 | ## Project context
|
9 | 10 | - Format: MDX files with YAML frontmatter
|
10 | 11 | - Config: docs.json for navigation, theme, settings
|
| 12 | + - See the docs.json schema: https://mintlify.com/docs.json |
11 | 13 | - Components: Mintlify components
|
12 | 14 |
|
13 | 15 | ## Content strategy
|
|
33 | 35 | - Relative paths for internal links
|
34 | 36 | - Use broadly applicable examples rather than overly specific business cases
|
35 | 37 | - Lead with context when helpful - explain what something is before diving into implementation details
|
36 |
| - |
37 |
| -### Style preferences (learned from content refresh project) |
38 |
| -#### Headings and formatting |
39 | 38 | - Use sentence case for all headings ("Getting started", not "Getting Started")
|
40 |
| -- Use "Properties" instead of "Props" for component documentation |
41 | 39 | - Use sentence case for code block titles ("Expandable example", not "Expandable Example")
|
| 40 | +- Prefer active voice and direct language |
| 41 | +- Remove unnecessary words while maintaining clarity |
| 42 | +- Break complex instructions into clear numbered steps |
| 43 | +- Make language more precise and contextual |
| 44 | +- Use [Lucide](https://lucide.dev) icon library |
42 | 45 |
|
43 |
| -#### Component introductions |
| 46 | +### Component introductions |
44 | 47 | - Start with action-oriented language: "Use [component] to..." rather than "The [component] component..."
|
45 | 48 | - Be specific about what components can contain or do
|
46 | 49 | - Make introductions practical and user-focused
|
47 | 50 |
|
48 |
| -#### Property descriptions |
| 51 | +### Property descriptions |
49 | 52 | - End all property descriptions with periods for consistency
|
50 | 53 | - Be specific and helpful rather than generic
|
51 | 54 | - Add scope clarification where needed (e.g., "For Font Awesome icons only:")
|
52 | 55 | - Use proper technical terminology ("boolean" not "bool")
|
53 | 56 |
|
54 |
| -#### Language and tone |
55 |
| -- Prefer active voice and direct language |
56 |
| -- Remove unnecessary words while maintaining clarity |
57 |
| -- Use "you complete" over "completing" for more direct communication |
58 |
| -- Break complex instructions into clear numbered steps |
59 |
| -- Make language more precise and contextual |
60 |
| - |
61 |
| -#### Code examples |
| 57 | +### Code examples |
62 | 58 | - Keep examples simple and practical
|
63 | 59 | - Use consistent formatting and naming
|
64 | 60 | - Provide clear, actionable examples rather than showing multiple options when one will do
|
65 | 61 |
|
66 |
| -#### Content organization |
| 62 | +## Content organization |
67 | 63 | - Structure content in the order users need it
|
68 | 64 | - Combine related information to reduce redundancy
|
69 | 65 | - Use specific links (direct to relevant pages rather than generic dashboards)
|
|
0 commit comments