Skip to content

Commit dd952bc

Browse files
committed
chore: add cursor rules
1 parent a1bc325 commit dd952bc

2 files changed

Lines changed: 131 additions & 0 deletions

File tree

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
description: Generate PR messages in markdown format for easy copy-paste to GitHub
3+
globs: *.md,*.mdc
4+
---
5+
6+
# PR Message Generation Rules
7+
8+
When generating PR messages, always follow these formatting guidelines for optimal GitHub compatibility.
9+
10+
## Emoji Guidelines
11+
- 🚀 for new features
12+
- 🔧 for fixes/improvements
13+
- ⚡ for performance optimizations
14+
- 🔐 for security/auth features
15+
- 🧹 for cleanup/maintenance
16+
- 📊 for metrics/analytics
17+
- 🧪 for testing
18+
- 🔄 for breaking changes
19+
- ✅ for completion/readiness
20+
21+
## Content Requirements
22+
- Always include a clear summary
23+
- List specific technical improvements
24+
- Mention file counts and code changes
25+
- Include commit references
26+
- Specify breaking changes or compatibility
27+
- Use bullet points for readability
28+
- Keep language professional but engaging
29+
30+
## GitHub Compatibility
31+
- Use proper markdown headers (##, ###)
32+
- Include horizontal rules (---) for separation
33+
- Use bold text (**text**) for emphasis
34+
- Use code blocks for technical details
35+
- Ensure proper line breaks for readability
36+
- Use checkboxes for status indicators

.cursorrules

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
# pp-dev - Cursor Rules
2+
3+
## Commit Message Guidelines
4+
5+
### Format: `<type>(<scope>): <subject>`
6+
- Use imperative mood ("add" not "added")
7+
- Don't capitalize first letter
8+
- No period at the end
9+
- Keep subject concise (50 chars or less)
10+
11+
### Commit Types (choose one):
12+
- **`feat`** - A new feature (triggers MINOR version bump)
13+
- **`fix`** - A bug fix (triggers PATCH version bump)
14+
- **`docs`** - Documentation only changes (NO version bump)
15+
- **`style`** - Code style changes, formatting, etc (NO version bump)
16+
- **`refactor`** - Code refactoring, no functional changes (NO version bump)
17+
- **`perf`** - Performance improvements (NO version bump)
18+
- **`test`** - Adding or updating tests (NO version bump)
19+
- **`chore`** - Maintenance tasks, dependencies, etc (NO version bump)
20+
- **`ci`** - CI/CD configuration changes (NO version bump)
21+
- **`build`** - Build system or external dependency changes (NO version bump)
22+
23+
### Scopes (optional, but recommended):
24+
- **`api`** - API-related changes
25+
- **`auth`** - Authentication/authorization changes
26+
- **`cli`** - CLI-related changes
27+
- **`ui`** - User interface changes (client toolbar)
28+
- **`build`** - Build system changes
29+
- **`ci`** - CI/CD changes
30+
- **`deps`** - Dependency updates
31+
- **`docs`** - Documentation changes
32+
- **`test`** - Testing changes
33+
- **`utils`** - Utility functions
34+
- **`config`** - Configuration changes
35+
- **`plugin`** - Vite plugin changes
36+
- **`middleware`** - Middleware changes
37+
38+
### Examples:
39+
```bash
40+
feat(api): add new authentication middleware
41+
fix(cli): resolve memory leak in data processing
42+
docs(readme): update installation instructions
43+
style: format code according to prettier rules
44+
refactor(utils): extract common validation functions
45+
perf(build): optimize bundle size
46+
test(e2e): add comprehensive login test suite
47+
chore(deps): update all dependencies to latest versions
48+
ci(github): add semantic-release workflow
49+
build(rollup): optimize bundle configuration
50+
```
51+
52+
### Breaking Changes:
53+
```bash
54+
feat(api): change response format structure
55+
56+
BREAKING CHANGE: API now returns data in different structure.
57+
All existing clients must be updated to handle new format.
58+
```
59+
60+
### Body and Footer Guidelines:
61+
- **Body**: Explain WHAT and WHY, not HOW
62+
- **Breaking Changes**: Start footer with "BREAKING CHANGE: <description>"
63+
64+
### Important Notes:
65+
- Only `feat`, `fix`, and `BREAKING CHANGE` trigger version bumps
66+
- Use scopes to indicate which area is affected
67+
- Be descriptive but concise
68+
- Reference related issues when possible
69+
- Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification
70+
71+
## General Development Guidelines
72+
73+
### Code Quality:
74+
- Always aim for clean, maintainable architecture
75+
- Focus on areas of the code relevant to the task
76+
- Do not touch code unrelated to the task
77+
- Avoid making major changes to working patterns unless explicitly instructed
78+
- Think about what other methods and areas might be affected by changes
79+
80+
### Semantic Release:
81+
- This project uses semantic-release for automated versioning
82+
- All releases go through Pull Requests (no direct pushes to main)
83+
- Commit messages determine version bumps automatically
84+
- Follow conventional commit format strictly for proper releases
85+
86+
### Project Structure:
87+
- `src/` - Source code
88+
- `src/api/` - MI API integration
89+
- `src/cli.ts` - CLI entry point
90+
- `src/client/` - Browser toolbar client
91+
- `src/lib/` - Core library functions
92+
- `src/plugins/` - Vite plugins
93+
- `bin/` - CLI binary
94+
- `tests/` - E2E tests
95+
- `dist/` - Build output

0 commit comments

Comments
 (0)