Cursor Rules for Java Spring Boot: .mdc Rule Set Generator

Prompt

Act as a senior Java Spring Boot engineer who maintains Cursor project rules (.cursor/rules/*.mdc files) so the Cursor agent writes code that matches an existing codebase instead of generic tutorial Spring.

Inputs:
- My build file (pom.xml or build.gradle), pasted: [BuildFile]
- Java version and Spring Boot version from that file, or "read it from BuildFile": [Versions]
- Package layout and layering, for example controller, service, repository, domain, dto: [PackageLayout]
- Persistence choices: JPA or JDBC, database, migration tool (Flyway or Liquibase), naming rules: [Persistence]
- Testing stack and conventions: JUnit 5, Mockito, Testcontainers, slice tests, naming: [TestingRules]
- Things the agent must never change or add (dependencies, generated code, secrets, config files): [NoTouch]
- Output format: [Format]

Generate:
1. A short read of BuildFile: the Java and Spring Boot versions, the starters in use, and anything that changes how code should be written (for example jakarta vs javax imports, Lombok present or not, WebFlux vs MVC). Only report what is actually in BuildFile.
2. A rule file plan: 4 to 6 .mdc files, each with a filename, one line purpose, and whether it is always applied or attached by globs.
3. The full text of each .mdc file with frontmatter (description, globs, alwaysApply) and a body of short, testable rules. Suggested split:
a. spring-core.mdc (alwaysApply): versions, constructor injection only, no field injection, configuration via @ConfigurationProperties, logging style.
b. web-layer.mdc (globs on controller packages): request and response DTOs, validation annotations, error handling through the existing exception handler, status codes.
c. persistence.mdc (globs on repository and entity packages): entity rules from Persistence, transaction boundaries in services, migrations through the named tool only, no schema auto update.
d. testing.mdc (globs on src/test): which test type to write for which layer, from TestingRules, naming pattern, no real network calls.
e. guardrails.mdc (alwaysApply): NoTouch items, ask before adding a dependency, never commit secrets, keep changes small.
4. For each rule file, two "bad vs good" Java snippets of three to eight lines showing the rule in this codebase's style.
5. A conflict check: rules that contradict each other or contradict BuildFile, with a suggested fix.
6. A test plan for the rules: three small tasks to give the Cursor agent and what correct output should look like.

Constraints:
- Do not invent libraries, starters, or plugins that are not in BuildFile. If a rule depends on something missing, say "add only if the team agrees".
- Keep each rule one line and checkable. No essays inside .mdc files.
- Do not claim Cursor features beyond rule files with description, globs, and alwaysApply frontmatter.

Instructions

Paste your build file and a short repo description into the [brackets], run it in Cursor chat or any model, then save each output block as its own .mdc file under .cursor/rules/. A single .cursorrules file is the legacy format; the current approach is .cursor/rules/*.mdc files, where a rule with globs is "Apply to Specific Files" and a rule with only a description is "Apply Intelligently". Review every rule before committing it.

Generated Output

This image was generated using the prompt above.

Cursor Rules for Java Spring Boot: .mdc Rule Set Generator - Result

Examples

Example Input

BuildFile: Maven pom.xml, spring-boot-starter-parent 3.3.x, java.version 21, starters: web, validation, data-jpa, security, actuator; flyway-core; postgresql; lombok; spring-boot-starter-test; testcontainers postgresql.
Versions: read it from BuildFile
PackageLayout: com.acme.billing.{api, service, repo, domain, api.dto}. Controllers only in api.
Persistence: JPA with PostgreSQL, Flyway migrations in db/migration named V{n}__snake_case.sql, table names snake_case plural.
TestingRules: JUnit 5 and Mockito for services, @WebMvcTest for controllers, @DataJpaTest with Testcontainers for repos. Test names should_doX_when_Y.
NoTouch: pom.xml dependencies, application-prod.yml, anything in generated/.
Format: one code block per file

Example Output

1. BUILD READ
Java 21, Spring Boot 3.3.x (jakarta.* imports, not javax). Spring MVC (starter-web), not WebFlux. Lombok present. Flyway plus PostgreSQL. Security and actuator starters present.

2. RULE FILE PLAN
spring-core.mdc, alwaysApply: versions and injection style
web-layer.mdc, globs **/api/**/*.java: controllers and DTOs
persistence.mdc, globs **/repo/**, **/domain/**, **/db/migration/**: JPA and Flyway
testing.mdc, globs src/test/**: test types and naming
guardrails.mdc, alwaysApply: no-touch list

3. FILES
--- spring-core.mdc
---
description: Core Spring Boot 3.3 conventions for the billing service
globs:
alwaysApply: true
---
- Java 21 and Spring Boot 3.3. Use jakarta.* imports only.
- Constructor injection with final fields. Never @Autowired on fields.
- Bind settings with @ConfigurationProperties records, not @Value scattered in classes.
- Use SLF4J via Lombok @Slf4j. No System.out.

--- persistence.mdc
---
description: JPA entities, repositories, and Flyway migrations
globs: **/repo/**/*.java, **/domain/**/*.java, **/db/migration/*.sql
alwaysApply: false
---
- Entities live in domain, repositories in repo.
- Tables are snake_case plural; set @Table(name = ...) explicitly.
- @Transactional goes on service methods. Do not add @Transactional to repositories or controllers.
- Schema changes only as a new Flyway file V{n}__snake_case.sql. Never edit an applied migration.
- Never set spring.jpa.hibernate.ddl-auto to update.

--- testing.mdc
---
description: Test types and naming
globs: src/test/**/*.java
alwaysApply: false
---
- Services: JUnit 5 plus Mockito, no Spring context.
- Controllers: @WebMvcTest with MockMvc.
- Repositories: @DataJpaTest with the Testcontainers PostgreSQL container.
- Name tests should_doX_when_Y.

--- guardrails.mdc
---
description: Files and actions the agent must not touch
globs:
alwaysApply: true
---
- Do not edit pom.xml dependencies. Propose them in chat instead.
- Do not edit application-prod.yml or anything in generated/.
- Never write secrets or passwords into code or YAML.

4. BAD VS GOOD (spring-core)
Bad:
@Autowired private InvoiceRepo repo;
Good:
private final InvoiceRepo repo;
InvoiceService(InvoiceRepo repo) { this.repo = repo; }

5. CONFLICT CHECK
None found. Note: Lombok is present, so @RequiredArgsConstructor is allowed if the team prefers it to hand written constructors. Pick one and state it.

6. RULE TEST PLAN
Task: "add an endpoint to void an invoice". Expect a DTO in api.dto, validation, a service method with @Transactional, a @WebMvcTest, and no pom.xml change.