|
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