Cursor with Spring Boot: Rules, Context, and Verification

Cursor with Spring Boot needs the same inputs a developer needs: the actual build, related code, and the behavior the change must preserve. A repository index can help locate code; it does not prove that a Spring bean is active or that a request is authorized.

This workflow uses a hypothetical orders endpoint. It does not claim production incidents, measured completion times, or a controlled comparison with another editor.

Establish a working baseline

Open the repository root rather than a generated output directory. Check the JDK, wrapper, and documented test command in a terminal. Run the baseline before requesting a change, so an existing failure is not attributed to the patch.

For a multi-module build, identify the module containing the application and the modules it depends on. The repository root, IDE workspace, Maven reactor, and agent working directory can differ. Include those details when a command works in one place and fails in another.

Use the current Cursor documentation for your installed interface and account. Feature names, shortcuts, and available models change; record them in an evaluation rather than treating an old screenshot as the interface contract.

Add a project rule with explicit scope

Cursor documents project instructions in Rules. A .cursor/rules/spring-boot.mdc can contain this example:

---
description: Java service conventions and verification
alwaysApply: true
---

- Read the wrapper and build before proposing a dependency or version change.
- Controllers delegate to services; services enforce ownership and business rules.
- Preserve existing DTOs, error contracts, and database migration history.
- List callers before changing shared behavior.
- After editing, run the documented verification task and report executed tests.
- Do not weaken a test or skip it merely to obtain a green build.

This is an instruction template, not a guarantee that the tool will comply. Mandatory architecture and access controls need executable enforcement and review. Keep build commands consistent with the project rather than hard-coding a different Boot version into the rule.

A rule saying “validate only in DTOs” is too broad: it can remove checks needed when the same service is invoked outside HTTP. Distinguish input-shape validation from business invariants.

Supply the code the task needs

For a change to order loading, provide the controller, service, repository query, authentication principal, and nearby tests. Ask Cursor to identify which symbols and files support its explanation. Check important exact references with repository search or IDE navigation.

Keep generated output out of retrieval where appropriate. The ignore-file documentation distinguishes indexing and other tool access. An ignore file is not a complete secret boundary; terminal commands or external tools may have access independent of the index.

The codebase-context guide covers how to diagnose an incorrect retrieved path. The rules guide covers activation and scope.

Example: adding a retry endpoint

Suppose an administrator can retry selected failed webhooks. A useful brief specifies more than “POST two IDs and assert 200”:

Reuse the existing retry service and response contract. Require the existing administrator authorization. Define handling for unknown IDs, non-retryable records, duplicates, and partial failures. Preserve the outbound idempotency key. Add tests for an administrator and an ordinary authenticated user.

Review the ownership or administrator check at the service boundary as well as in the controller. Confirm a repeated request cannot create an unintended duplicate external action. If these rules are absent from the repository, establish them before asking the agent to implement a plausible policy.

Verify startup and behavior

Compilation cannot establish profile-dependent bean wiring. Run an appropriate context-load or application test with the relevant profile. For persistence changes, exercise the query and representative relations, not only a mocked repository.

Inspect dependency changes separately. A new starter might be correct, redundant, or change auto-configuration. Check the dependency tree and the specific feature it enables. A resolving artifact is not proof of an active integration.

Review generated assertions using the JUnit checklist. For query-performance risks, use an integration check that can observe database access; do not claim that all tests either catch or miss N+1 behavior.

Finally, read the diff, rerun the project verification task, and record blocked checks. Compare this process with the Claude Code workflow or the Java tool-selection worksheet using the same acceptance criteria. The Java hub provides the broader map.