Skip to content

Commit db0892a

Browse files
Cybertron01ZCybertron01Z
authored
Merge pull request #395 from Zuehlke/feat/cursor-rules
feat: add cursor rules
2 parents 07b2b77 + 0eba2ed commit db0892a

File tree

4 files changed

+195
-0
lines changed

4 files changed

+195
-0
lines changed

‎.cursor/rules/code-quality.mdc‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
---
2+
description:
3+
globs:
4+
alwaysApply: true
5+
---
6+
# Code Quality Guidelines
7+
8+
## Verify Information
9+
Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
10+
11+
## File-by-File Changes
12+
Make changes file by file and give me a chance to spot mistakes.
13+
14+
## No Apologies
15+
Never use apologies.
16+
17+
## No Understanding Feedback
18+
Avoid giving feedback about understanding in comments or documentation.
19+
20+
## No Whitespace Suggestions
21+
Don't suggest whitespace changes.
22+
23+
## No Summaries
24+
Don't summarize changes made.
25+
26+
## No Inventions
27+
Don't invent changes other than what's explicitly requested.
28+
29+
## No Unnecessary Confirmations
30+
Don't ask for confirmation of information already provided in the context.
31+
32+
## Preserve Existing Code
33+
Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
34+
35+
## Single Chunk Edits
36+
Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
37+
38+
## No Implementation Checks
39+
Don't ask the user to verify implementations that are visible in the provided context.
40+
41+
## No Unnecessary Updates
42+
Don't suggest updates or changes to files when there are no actual modifications needed.
43+
44+
## Provide Real File Links
45+
Always provide links to the real files, not x.md.
46+
47+
## No Current Implementation
48+
Don't show or discuss the current implementation unless specifically requested.

‎.cursor/rules/poinz.mdc‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
description:
3+
globs: client/**/*.js,client/**/*.jsx
4+
alwaysApply: false
5+
---
6+
# Poinz rules
7+
8+
- we are still using javascript
9+
- if you are working on a js file, do not create a ts file, do everything in the javascript file
10+
11+
- NEVER FINISH BEFORE YOU ARE NOT FINISHED, I DO NOT WANT TO HEAR "should I continue?"

‎.cursor/rules/react.mdc‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
---
2+
description:
3+
globs:
4+
alwaysApply: true
5+
---
6+
# React Best Practices
7+
8+
## Component Structure
9+
- Use functional components over class components
10+
- Keep components small and focused
11+
- Extract reusable logic into custom hooks
12+
- Use composition over inheritance
13+
- Split large components into smaller, focused ones
14+
15+
## Hooks
16+
- Follow the Rules of Hooks
17+
- Use custom hooks for reusable logic
18+
- Keep hooks focused and simple
19+
- Use appropriate dependency arrays in useEffect
20+
- Implement cleanup in useEffect when needed
21+
- Avoid nested hooks
22+
23+
## State Management
24+
- Keep state as close to where it's used as possible
25+
- Avoid prop drilling through proper state management
26+
27+
## Performance
28+
- Implement proper memoization (useMemo, useCallback)
29+
- Use React.memo for expensive components
30+
- Avoid unnecessary re-renders
31+
- Implement proper lazy loading
32+
- Use proper key props in lists
33+
- Profile and optimize render performance
34+
35+
## Forms
36+
- Use controlled components for form inputs
37+
- Implement proper form validation
38+
- Handle form submission states properly
39+
- Show appropriate loading and error states
40+
- Use form libraries for complex forms
41+
- Implement proper accessibility for forms
42+
43+
## Error Handling
44+
- Implement Error Boundaries
45+
- Handle async errors properly
46+
- Show user-friendly error messages
47+
- Implement proper fallback UI
48+
- Log errors appropriately
49+
- Handle edge cases gracefully
50+
51+
## Accessibility
52+
- Use semantic HTML elements
53+
- Implement proper ARIA attributes
54+
- Ensure keyboard navigation
55+
- Test with screen readers
56+
- Handle focus management
57+
- Provide proper alt text for images
58+
59+
## Code Organization
60+
- Group related components together
61+
- Use proper file naming conventions
62+
- Implement proper directory structure
63+
- Keep styles close to components
64+
- Use proper imports/exports
65+
- Document complex component logic

‎.cursor/rules/usage-standard.mdc‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
---
2+
description:
3+
globs:
4+
alwaysApply: true
5+
---
6+
1. CONTEXT FIRST — NO GUESSWORK
7+
• DO NOT WRITE A SINGLE LINE OF CODE UNTIL YOU UNDERSTAND THE SYSTEM.
8+
• IMMEDIATELY LIST FILES IN THE TARGET DIRECTORY.
9+
• ASK ONLY THE NECESSARY CLARIFYING QUESTIONS. NO FLUFF.
10+
• DETECT AND FOLLOW EXISTING PATTERNS. MATCH STYLE, STRUCTURE, AND LOGIC.
11+
• IDENTIFY ENVIRONMENT VARIABLES, CONFIG FILES, AND SYSTEM DEPENDENCIES.
12+
13+
2. CHALLENGE THE REQUEST — DO NOT BLINDLY FOLLOW
14+
• IDENTIFY EDGE CASES IMMEDIATELY.
15+
• ASK SPECIFICALLY: WHAT ARE THE INPUTS? OUTPUTS? CONSTRAINTS?
16+
• QUESTION EVERYTHING THAT IS VAGUE OR ASSUMED.
17+
• REFINE THE TASK UNTIL THE GOAL IS BULLET-PROOF.
18+
19+
3. HOLD THE STANDARD — EVERY LINE MUST COUNT
20+
• CODE MUST BE MODULAR, TESTABLE, CLEAN.
21+
• COMMENT METHODS. USE DOCSTRINGS. EXPLAIN LOGIC.
22+
• SUGGEST BEST PRACTICES IF CURRENT APPROACH IS OUTDATED.
23+
• IF YOU KNOW A BETTER WAY — SPEAK UP.
24+
25+
4. ZOOM OUT — THINK BIGGER THAN JUST THE FILE
26+
• DO NOT PATCH. DESIGN.
27+
• THINK ABOUT MAINTAINABILITY, USABILITY, SCALABILITY.
28+
• CONSIDER ALL COMPONENTS (FRONTEND, BACKEND, DB, USER INTERFACE).
29+
• PLAN FOR THE USER EXPERIENCE. NOT JUST THE FUNCTIONALITY.
30+
31+
5. WEB TERMINOLOGY — SPEAK THE RIGHT LANGUAGE
32+
• FRAME SOLUTIONS IN TERMS OF APIs, ROUTES, COMPONENT STRUCTURE, DATA FLOW.
33+
• UNDERSTAND FRONTEND-BACKEND INTERACTIONS BEFORE CHANGING EITHER.
34+
35+
6. ONE FILE, ONE RESPONSE
36+
• DO NOT SPLIT FILE RESPONSES.
37+
• DO NOT RENAME METHODS UNLESS ABSOLUTELY NECESSARY.
38+
• SEEK APPROVAL ONLY WHEN THE TASK NEEDS CLARITY — OTHERWISE, EXECUTE.
39+
40+
7. ENFORCE STRICT STANDARDS
41+
• CLEAN CODE, CLEAN STRUCTURE.
42+
• 1600 LINES PER FILE MAX.
43+
• HIGHLIGHT ANY FILE THAT IS GROWING BEYOND CONTROL.
44+
• USE LINTERS, FORMATTERS. IF THEY ARE MISSING — FLAG IT.
45+
46+
8. MOVE FAST, BUT WITH CONTEXT
47+
• ALWAYS BULLET YOUR PLAN BEFORE EXECUTION:
48+
• WHAT YOU ARE DOING
49+
• WHY YOU ARE DOING IT
50+
• WHAT YOU EXPECT TO CHANGE
51+
52+
ABSOLUTE DO-NOTS:
53+
• DO NOT CHANGE TRANSLATION KEYS UNLESS SPECIFIED.
54+
• DO NOT ADD LOGIC THAT DOES NOT NEED TO BE THERE.
55+
• DO NOT WRAP EVERYTHING IN TRY-CATCH. THINK FIRST.
56+
• DO NOT SPAM FILES WITH NON-ESSENTIAL COMPONENTS.
57+
• DO NOT CREATE SIDE EFFECTS WITHOUT MENTIONING THEM.
58+
59+
REMEMBER:
60+
• YOUR WORK IS NOT DONE UNTIL THE SYSTEM IS STABLE.
61+
• THINK THROUGH ALL CONSEQUENCES OF YOUR CHANGES.
62+
• IF YOU BREAK SOMETHING IN ONE PLACE, FIX IT ACROSS THE PROJECT.
63+
• CLEANUP. DOCUMENT. REVIEW.
64+
65+
THINK LIKE A HUMAN:
66+
• CONSIDER NATURAL BEHAVIOUR.
67+
• HOW WOULD A USER INTERACT WITH THIS?
68+
• WHAT HAPPENS WHEN SOMETHING FAILS?
69+
• HOW CAN YOU MAKE THIS FEEL SEAMLESS?
70+
71+
EXECUTE LIKE A PROFESSIONAL CODER. THINK LIKE AN ARCHITECT. DELIVER LIKE A LEADER.

0 commit comments

Comments
 (0)
⚡