Skip to content

Commit 922d33b

Browse files
mergify[bot]mergify[bot]
authored
Merge of #7794 
2 parents aaf21a8 + 0772b80 commit 922d33b

File tree

1 file changed

+166
-0
lines changed

1 file changed

+166
-0
lines changed

‎.cursor/rules/conventional-commits.mdc‎

Lines changed: 166 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,166 @@
1+
---
2+
description: Enforce Conventional Commits specification for all commits and pull requests
3+
globs:
4+
alwaysApply: true
5+
---
6+
7+
# Conventional Commits Guidelines
8+
9+
When creating commits, suggesting commit messages, or creating pull requests, ALWAYS follow the Conventional Commits specification strictly.
10+
11+
## Commit Message Format
12+
13+
Every commit message MUST follow this exact format:
14+
15+
```
16+
<type>[optional scope]: <description>
17+
18+
[optional body]
19+
20+
[optional footer(s)]
21+
```
22+
23+
## Commit Types (REQUIRED)
24+
25+
You MUST use one of these commit types:
26+
27+
- `feat`: A new feature
28+
- `fix`: A bug fix
29+
- `docs`: Documentation only changes
30+
- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
31+
- `refactor`: A code change that neither fixes a bug nor adds a feature
32+
- `perf`: A code change that improves performance
33+
- `test`: Adding missing tests or correcting existing tests
34+
- `build`: Changes that affect the build system or external dependencies
35+
- `ci`: Changes to CI configuration files and scripts
36+
- `chore`: Other changes that don't modify src or test files
37+
- `revert`: Reverts a previous commit
38+
39+
## Scope (OPTIONAL)
40+
41+
The scope should be the name of the affected component, module, or area. Keep it concise and meaningful.
42+
43+
### Good scope examples:
44+
- `feat(auth): add OAuth2 support`
45+
- `fix(api): handle null values in user endpoint`
46+
- `docs(readme): update installation instructions`
47+
- `refactor(database): optimize query performance`
48+
49+
## Description (REQUIRED)
50+
51+
The description MUST:
52+
- Use the imperative, present tense: "change" not "changed" nor "changes"
53+
- NOT capitalize the first letter
54+
- NOT include a period (.) at the end
55+
- Be concise (max 50 characters recommended, 72 absolute max)
56+
- Complete the sentence: "If applied, this commit will..."
57+
58+
### Good descriptions:
59+
- ✅ `add user authentication`
60+
- ✅ `fix memory leak in data processing`
61+
- ✅ `update dependencies to latest versions`
62+
63+
### Bad descriptions:
64+
- ❌ `Added user authentication` (past tense)
65+
- ❌ `Fix memory leak.` (has period)
66+
- ❌ `Updates dependencies` (wrong tense)
67+
- ❌ `Fixed bug` (too vague)
68+
69+
## Body (OPTIONAL)
70+
71+
The body should:
72+
- Use the imperative, present tense
73+
- Explain the motivation for the change
74+
- Contrast with previous behavior
75+
- Wrap lines at 72 characters
76+
- Be separated from the description by a blank line
77+
78+
## Footer (OPTIONAL)
79+
80+
The footer should:
81+
- Reference issues: `Fixes #123`, `Closes #456`, `Resolves #789`
82+
- Note breaking changes: Start with `BREAKING CHANGE:`
83+
- Be separated from the body by a blank line
84+
85+
## Complete Examples
86+
87+
### Simple feature commit:
88+
```
89+
feat: implement user profile page
90+
```
91+
92+
### Bug fix with scope:
93+
```
94+
fix(auth): prevent token expiration during active session
95+
```
96+
97+
### Feature with body:
98+
```
99+
feat(payment): add support for cryptocurrency payments
100+
101+
Integrate with multiple blockchain networks to allow users
102+
to pay with Bitcoin, Ethereum, and other major cryptocurrencies.
103+
This includes wallet connection and transaction verification.
104+
```
105+
106+
### Breaking change with footer:
107+
```
108+
feat(api)!: restructure user endpoint responses
109+
110+
Standardize all API responses to use consistent envelope
111+
format with data, error, and metadata fields.
112+
113+
BREAKING CHANGE: API responses now wrap data in a 'data'
114+
field instead of returning it at the root level. Clients
115+
must update to access response.data instead of response.
116+
117+
Fixes #234
118+
```
119+
120+
### Revert commit:
121+
```
122+
revert: feat(payments): add cryptocurrency support
123+
124+
This reverts commit abc123def456. The cryptocurrency
125+
integration is causing performance issues in production
126+
that need to be addressed before re-implementing.
127+
```
128+
129+
## Pull Request Guidelines
130+
131+
Pull request titles MUST follow the same conventional commit format:
132+
- Use appropriate type prefix
133+
- Include scope when relevant
134+
- Keep title under 72 characters
135+
- Use imperative mood
136+
137+
### PR Title Examples:
138+
- ✅ `feat(ui): implement dark mode toggle`
139+
- ✅ `fix: resolve race condition in data sync`
140+
- ✅ `docs: add API migration guide`
141+
- ❌ `Updated UI components` (no type, past tense)
142+
- ❌ `BUGFIX: Fixed the login issue` (wrong format)
143+
144+
## Critical Rules for Implementation
145+
146+
1. **NEVER suggest non-conventional formats** - Always use the exact format specified above
147+
2. **NEVER use past tense** - Always use imperative mood
148+
3. **NEVER capitalize the description** - First letter must be lowercase
149+
4. **NEVER add periods to descriptions** - No punctuation at the end
150+
5. **ALWAYS pick the most accurate type** - Don't use `chore` when `fix` is more appropriate
151+
6. **ALWAYS be specific** - Vague commits like "fix bug" or "update code" are not acceptable
152+
153+
## Validation Checklist
154+
155+
Before suggesting any commit message, verify:
156+
- [ ] Has a valid type from the allowed list
157+
- [ ] Description is in imperative mood
158+
- [ ] Description starts with lowercase letter
159+
- [ ] No period at the end of description
160+
- [ ] Description clearly explains what the commit does
161+
- [ ] Scope is appropriate (if used)
162+
- [ ] Body provides context (if needed)
163+
- [ ] Footer references issues (if applicable)
164+
- [ ] Breaking changes are clearly marked
165+
166+
When helping users write commits, actively guide them to follow these conventions and explain why each rule matters for maintaining a clean, parseable git history.

0 commit comments

Comments
 (0)