-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path.cursorrules
201 lines (153 loc) · 5 KB
/
.cursorrules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
# Rules
---
## Writing Markdown
---
- In Markdown, fenced code blocks should be surrounded by blank lines
### Example of a properly formatted fenced code block
```md
1. Example of a properly formatted fenced code block
```bash
echo "Like this!"
```
```
## Frontmatter
### Aliases
- For translated content, only the English (en) version should have `/docs` root aliases. Other language versions should only have their language-specific aliases (e.g. `/ja/docs` for Japanese)
#### Example of a properly formatted aliases in the frontmatter
```yaml
<!-- For the English version -->
---
title: "Tracking Training Changes"
description: "Guide to keeping track of changes during LoRA training using automated scripts"
summary: "Learn how to use automated scripts to organize and track your LoRA training process, including managing model versions, backing up configurations, and maintaining clean training workspaces."
weight: 8
bookToC: false
bookFlatSection: false
aliases:
- /en/docs/yiff_toolkit/lora_training/Tracking-Training-Changes/
- /en/docs/yiff_toolkit/lora_training/Tracking-Training-Changes
- /en/docs/yiff_toolkit/lora_training/Tracking_Training_Changes/
- /en/docs/yiff_toolkit/lora_training/Tracking_Training_Changes
- "/en/docs/yiff_toolkit/lora_training/Tracking Training Changes/"
- "/en/docs/yiff_toolkit/lora_training/Tracking Training Changes"
- /docs/yiff_toolkit/lora_training/Tracking-Training-Changes/
- /docs/yiff_toolkit/lora_training/Tracking-Training-Changes
- /docs/yiff_toolkit/lora_training/Tracking_Training_Changes/
- /docs/yiff_toolkit/lora_training/Tracking_Training_Changes
- "/docs/yiff_toolkit/lora_training/Tracking Training Changes/"
- "/docs/yiff_toolkit/lora_training/Tracking Training Changes"
---
<!-- For the Hungarian version -->
---
title: "Tanítási Változások Követése"
description: "Útmutató a LoRA tanítás során történő változások követéséhez automatizált szkriptek segítségével"
summary: "Ismerje meg, hogyan használhat automatizált szkripteket a LoRA tanítási folyamat rendszerezéséhez és követéséhez, beleértve a modellverziók kezelését, a konfigurációk biztonsági mentését és a tiszta tanítási munkakörnyezet fenntartását."
weight: 8
bookToC: false
bookFlatSection: false
aliases:
- /hu/docs/yiff_toolkit/lora_training/Tracking-Training-Changes/
- /hu/docs/yiff_toolkit/lora_training/Tracking-Training-Changes
- /hu/docs/yiff_toolkit/lora_training/Tracking_Training_Changes/
- /hu/docs/yiff_toolkit/lora_training/Tracking_Training_Changes
- "/hu/docs/yiff_toolkit/lora_training/Tracking Training Changes/"
- "/hu/docs/yiff_toolkit/lora_training/Tracking Training Changes"
---
```
## Hugo Templates
- Ignore linter errors for Hugo template syntax like `{{ . | safeJS }}` within `<script>` tags - these are valid Hugo template expressions
## SCSS/CSS Styling
### File Organization
- SCSS partials should be prefixed with an underscore (e.g. `_blurhash.scss`)
- All SCSS partials should be imported in `_main.scss`
- Each component should have its own SCSS partial file
- Global styles and variables should be in `_main.scss`
### Import Order
The import order in `_main.scss` should be:
1. Variables and mixins
2. Base styles
3. Components
4. Utilities
5. Third-party styles
Example:
```scss
// Variables and mixins first
@import "variables";
@import "mixins";
// Base styles
@import "defaults";
@import "fonts";
// Components
@import "markdown";
@import "shortcodes";
@import "images";
// Utilities
@import "utils";
@import "print";
// Third-party
@import "blurhash";
```
### Naming Conventions
- Use kebab-case for class names (e.g. `image-container`)
- Prefix classes with component name for scoping (e.g. `book-menu`, `book-toc`)
- Use BEM-like naming for modifiers (e.g. `book-menu--collapsed`)
### Media Queries
- Define breakpoints as variables in `_main.scss`
- Use mobile-first approach
- Include media queries within the component styles
Example:
```scss
.component {
// Mobile styles first
width: 100%;
// Then tablet
@media screen and (min-width: $tablet-breakpoint) {
width: 50%;
}
// Then desktop
@media screen and (min-width: $desktop-breakpoint) {
width: 33.33%;
}
}
```
### Performance
- Avoid deeply nested selectors (max 3 levels)
- Use CSS Grid and Flexbox for layouts
- Minimize use of `!important`
- Use CSS variables for theme colors and values that change with user preferences
Example:
```scss
// Good
.image-container {
.blur-hash {
width: 100%;
}
}
// Bad - too deeply nested
.container {
.wrapper {
.image {
.blur-hash {
width: 100%;
}
}
}
}
```
### Theme Variables
- Define theme variables in `:root`
- Use semantic naming for variables
- Include both light and dark theme values
Example:
```scss
:root {
// Light theme
--body-background: #ffffff;
--body-font-color: #000000;
// Dark theme
@media (prefers-color-scheme: dark) {
--body-background: #1a1a1a;
--body-font-color: #ffffff;
}
}
```