Rules

First in Cursor, Rules refer to custom configurations or behavioral rules of a code editor, which are usually used to control code style, formatting, static analysis, or constraints when AI generates code. Specifically, Rules can involve code formatting rules, constraints on AI generated code, project-specific specifications, etc.

At present, no matter what kind of large model, there will be a limit on the length of the context, especially for multi-round dialogue scenarios like ours. For the same function, the implementation given by Cursor may be different. Therefore, for our project development, I think it is unacceptable to fail to ensure the consistency of the code.

How to create a Rule from scratch

If the project is from 0 to 1, please let Cursor ( using claude-3.7-sonnet-thinking ) help us generate a preliminary version of Rules

No need for complicated prompts: I want to develop a backend project with front-end and back-end separation. Please use Java language and develop the project from scratch. Please help me generate a Rules file in Cursor (markdown format) so that our backend project can implement functions according to modern standard processes. Please be as complete as possible.

As a result, 12 major rules are generated, which are basically usable. If you have a programming foundation, it is best to add your own familiar technology stack to facilitate subsequent maintenance.

  com.company.project
    ├── config # Configuration class
    ├── controller
    ├── service # Service interface
    │ └── impl # Service implementation
    ├── repository #Data access interface
    │ └── impl # Data access implementation (if needed)
    ├── model #Data model
    │ ├── entity # Database entity
    │ ├── dto #Data transfer object
    │ ├── vo # View object
    │ └── enums # Enumeration type
    ├── util # Utility class
    ├── exception # Custom exception
    ├── constant # Constant definition
    └── aspect # Aspect class

How to maintain rules

Now, let Cursor complete the initialization of the project according to the above Rules, and let it help us generate an accessible demo application. After testing the demo function, we can officially start the development of the project function.

Then, we let Cursor implement the first module of the project. The function does not need to be too complicated, but the process involved can be complete. After the function is implemented, let Cursor reflect and think, let it give optimization and suggestions, and consider the code specifications and implementation process, let it optimize our first module code

After the first function is completed, let Cursor iteratively update the content of our Rules file: Based on the currently implemented xx functional module, please summarize the code specifications and implementation process, and add them to our xxx rule file as a specification constraint for subsequent implementation of other modules

At this point, the subsequent development of our other module functions can be implemented based on this Rules file, so that all our codes are consistent.

In general, we should be good at letting Cursor's own capabilities help us maintain the contents of the Rules file

Front-end and back-end development process

It is a common practice to separate the front-end and back-end of a project. How to make Cursor efficiently help us realize the functions of the front-end and back-end projects is also another headache. After trying many methods, I summarized a set of feasible methods.

Open our front-end and back-end projects at the same time in one workspace to facilitate subsequent interactive development

Then for the development of functions, we first let Cursor help us realize the complete front-end functions, but for the calling part of the interface, we require the use of mock data return, so that we can focus on the development and debugging of the front-end function page

After the page functions are completed, we can focus on the development of the backend. First, use the mock data structure in the front-end project to generate a model of our back-end data. It is recommended to use MySQL MCP to automatically help us manage the creation of the database. Then, using these model data, we can implement some template management functions of the backend.

Finally, add some API call files involved in the front-end project to the context, and then add our back-end interface entry directory to the context. Then let Cursor implement the docking development with the back-end interface based on the front-end interface call, modify or add the back-end interface function, so that we can complete the linkage development of our front-end and back-end projects.

Summarize

In general, we can use more general rules to constrain the beginning of our project. As the project is iterated and upgraded, we should spend more time maintaining the Rules and make them specific rules applicable to our current project.

The significance of tools is to liberate our creativity. We hope to achieve the effect that, as Rules are improved, the number of times we need to manually participate in the subsequent functional development of the project should be reduced. In this way, we can have more energy to focus on thinking and innovation.