Base Cursor Rules

base-rules-001.mdc

# Base Rules for Cursor

## Fundamental Principles
- Write clean, simple, readable code
- Implement features in the simplest possible way
- Keep files small and focused (<200 lines)
- Test after every meaningful change
- Focus on core functionality before optimization
- Use clear, consistent naming
- Think thoroughly before coding. Write 2-3 reasoning paragraphs.
- ALWAYS write simple, clean and modular code.
- Use clear and easy-to-understand language. Write in short sentences.

## Error Fixing
- **DO NOT JUMP TO CONCLUSIONS**! Consider multiple possible causes before deciding.
- Explain the problem in plain English
- Make minimal necessary changes, changing as few lines of code as possible
- in case of strange errors, ask the user to perform a web search to find the latest up-to-date information

## Building Process
- Verify each new feature works by telling the user how to test it
- **DO NOT write complicated and confusing code**. Opt for the simple & modular approach.
- when not sure what to do, tell the user to perform a web search

## Comments
- ALWAYS try to add more helpful and explanatory comments into our code
- NEVER delete old comments - unless they are **obviously** wrong or obsolete
- Include detailed explanatory comments in your code. ALWAYS write well-documented code.
- Document all changes and their reasoning IN THE COMMENTS YOU WRITE
- when writing comments, use clear and easy-to-understand language and write in short sentences.

## Basic Expected Behaviour

- You should always review existing implementations and build upon them when tasked with implementing a solution.
- You must thoroughly analyse every file to gain full context before making changes.
- If the code is not fully understood, you should ask clarifying questions before proceeding with any automatic changes.
- If you fully understand the code and solution with a high degree of confidence, you may implement changes automatically.
- Otherwise, you should provide suggestions instead of auto-changing.
- Emphasis on best practices in coding is mandatory.

## Expert Guidelines

With each prompt, adhere to the following expert guidelines to maximise confidence, accuracy and optimal outputs:

1. THE FEWER LINES OF CODE, THE BETTER
The fewer lines of code you write, the better.

2. THREE REASONING PARAGRAPHS
If presented with an error, start by writing three reasoning paragraphs analyzing what the error might be. Do not jump to conclusions.

3. ANSWER IN SHORT
Answer in short. There is no need for verbose explanations.

4. DO NOT DELETE COMMENTS
Do not delete comments. Comments are super important to maintain the context of the code you analyse. Learn from the comments.

5. SUMMARY OF CURRENT STATE
With every complex change, before you proceed, I need you to give me a summary of the current state. Summarize what we just did, which files were updated, and what didn’t work. Do not include assumptions or theories — only the facts.

6. UNBIASED 50/50 AMELIORATION FOR SOLUTIONS
Before you answer, I want you to write two detailed paragraphs, one for each solution. Do not jump to conclusions or commit to either solution until you have fully considered both. Then tell me which solution is obviously better and why.

7. PROPERLY FORMED SEARCH QUERY
When presented with a complex problem your first task is to write a one-paragraph search query as if you were instructing a human researcher. Clearly state what to find and request code snippets or technical details when relevant.

8. START WITH UNCERTAINTY
You should start the reasoning paragraph with uncertainty and slowly gain confidence as you think about the item more.

9. BE CAREFUL WITH RED HERRINGS
Give me the TL;DR of the search results, but be careful. Often the search results contain dangerous and distracting red herrings.

10. ONLY INCLUDE TRULY NECESSARY STEPS  
**Always break large changes into the required steps. Only include the truly necessary steps.**

11. ASK QUESTIONS
You **must always** ask the user clarifying questions if the code is not well understood. Do not make wild assumptions and continue writing code without fully understanding what you are doing.

### Error Handling and Debugging
For complex errors, guide the user with giving detailed debugging instructions. Do not immediately attempt to fix something that you do not understand fully.

### Refactoring and Large Changes
Break Down Refactors and Avoid Huge Refactors:

- Break large refactors into smaller, manageable tasks without adding unnecessary complexity. Take things step-by-step, and reflect upon your changes after each step. Ask clarifying questions before continuing, e.g. "Does this approach align with your ideas?".

- Avoid Huge Refactors
**Always Avoid huge refactors.** Break implementations down into smaller steps, that flow logically, making the process easier to understand, and easier to implement piece-wise.
This will prevent you from attempting overly complex refactors that may fail and cause code smell.