Spring Boot prompts for ChatGPT, Claude and Codex

These 13 Spring Boot prompts help ChatGPT, Claude, Claude Code and Codex write Spring Boot code that compiles against your version: upgrades to Spring Boot 4, REST APIs with validation and versioning, JPA queries without N+1 problems, tests with slices and Testcontainers, and production setup with Actuator and virtual threads. Each prompt is a template with blanks you fill in.

For plain Java work outside Spring, the Java prompts cover records, sealed types and JDK upgrades.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{boot_version:4.1}} means Spring Boot 4.1 unless you change it.

State your Spring Boot and Java versions. The Spring Boot system requirements say Spring Boot 4.1.2 "requires at least Java 17 and is compatible with versions up to and including Java 27," with Spring Framework 7.0.10 or above. Spring Boot 4 changed a lot: modular starters, Jackson 3, and removed test annotations. A model that assumes Spring Boot 3 will write code that no longer compiles.

Paste the build file with the code. Starters, the Java version and the database driver in pom.xml or build.gradle decide which auto-configuration applies.

In an agent, let it run the tests after each change. Many errors in Spring only appear when the application context starts, so a compiling change is not a working one.

What changed in Spring Boot 4 that AI gets wrong?

A model that assumes Spring Boot 3 may suggest APIs that Spring Boot 4 removed or replaced. This table, from the Spring Boot 4.0 migration guide and release notes, lists the changes worth naming in your prompt.

If your project is still on Spring Boot 3, say so in the prompt, and the model should stick to the left column.

How do you upgrade to Spring Boot 4?

1. Plan an upgrade from Spring Boot 3

The Spring Boot 4.0 migration guide says: "Before you start the upgrade, make sure to upgrade to the latest available 3.5.x version." It also covers modular starters, the removal of @MockBean and @SpyBean, and the move to Jackson 3.

Plan an upgrade from Spring Boot {{from:3.4}} to {{to:4.1}}. Here is
our build file and a list of the starters and libraries we use:

{{build_file}}

Order the steps: move to the latest 3.5.x and fix deprecation
warnings, then switch to 4.x. For each step, list the starter changes
(new modular starters and their test companions), Jackson 3 import
changes from com.fasterxml.jackson to tools.jackson, test changes
(@MockitoBean, @AutoConfigureMockMvc), and third-party libraries that
need new major versions. Add spring-boot-properties-migrator for
renamed properties and remind me to remove it after. Mark anything
you're unsure applies.

2. Fix tests that broke after the upgrade

These tests passed on Spring Boot 3 and fail on Spring Boot 4:

{{tests_and_errors}}

For each failure, explain the cause. Check for: @MockBean or @SpyBean
(removed, use @MockitoBean and @MockitoSpyBean), @SpringBootTest tests
that inject MockMvc without @AutoConfigureMockMvc, missing
spring-boot-starter-<technology>-test companions, and Jackson 3
serialization differences. Show the fixed tests and the build file
changes.

How do you build a REST API in Spring Boot?

3. Build a CRUD endpoint with validation

Build a REST API for {{resource:projects}} in Spring Boot
{{boot_version:4.1}} with Spring MVC.

Fields and rules:
{{spec}}

Use a record for request and response DTOs separate from the entity,
Jakarta Bean Validation annotations with @Valid, and a service layer
with @Transactional on writes. Return 201 with a Location header on
create, 404 for missing records and 409 for conflicts. Add a
@RestControllerAdvice that returns ProblemDetail responses. Show the
controller, DTOs, service and the error handler.

4. Add API versioning

The Spring Boot 4.0 release notes add auto-configuration for API versioning in Spring MVC and WebFlux, set through spring.mvc.apiversion.* or spring.webflux.apiversion.* properties.

We need two versions of {{endpoint:GET /api/orders}} at the same time.
Current controller:

{{controller}}

Add API versioning with Spring Boot 4's built-in support. Recommend
where the version should come from ({{source:a request header}}, a
path segment or a query parameter), show the spring.mvc.apiversion
properties, and map version 1 and 2 to separate handler methods with
shared logic in the service. Add MockMvc tests for both versions and
for a request with no version.

5. Call another service with an HTTP interface

Spring Boot 4 auto-configures HTTP service clients: plain Java interfaces annotated with @HttpExchange become generated client implementations.

Write a client for this external API using an @HttpExchange interface
in Spring Boot {{boot_version:4.1}}:

{{api_docs}}

Define the interface with typed request and response records, set the
base URL and timeouts in application properties, and map 4xx and 5xx
responses to our own exceptions. Add retries only for safe, idempotent
calls. Show a test that stubs the external API and covers a success,
a 404 and a timeout.

How do you write JPA code that stays fast?

6. Find and fix N+1 queries

This endpoint runs {{count:120}} SQL queries. Here are the entities,
the repository and the service method:

{{code}}

Turn on SQL logging and explain which access triggers each extra
query. Fix it with a fetch join, an @EntityGraph on the repository
method, or a DTO projection, and say which fits each case. Check for
lazy loading outside the transaction and for open-in-view hiding the
problem. Add a test that asserts the query count.

7. Design entities and a migration from a spec

Design JPA entities and a {{tool:Flyway}} migration for:

{{spec}}

Choose ID generation, column types and lengths, unique constraints and
indexes for the queries in the spec. Model relationships with the
owning side explained, LAZY fetching by default, and cascade only where
the child can't exist alone. Avoid bidirectional mappings we don't
need. Show the entities, the SQL migration and a repository with the
main queries.

How do you test a Spring Boot app?

8. Write a web layer test with @WebMvcTest

The Spring Boot testing docs say @WebMvcTest limits scanned beans to controllers and web components, and that "Regular @Component and @ConfigurationProperties beans are not scanned."

Write @WebMvcTest tests for this controller:

{{controller}}

Mock the service with @MockitoBean. Cover a valid request, each
validation error, a missing record, and an unauthenticated request if
security applies. Assert status, JSON body and headers. Keep the
tests fast: no database and no full application context. List any
bean the controller needs that the slice won't load.

9. Test against a real database with Testcontainers

The Testcontainers docs describe @ServiceConnection, which creates connection details for a container so the auto-configuration connects to it, overriding connection properties.

Set up integration tests against a real {{database:PostgreSQL}} with
Testcontainers in Spring Boot {{boot_version:4.1}}.

Our build file and one repository:
{{code}}

Define the container as a bean with @ServiceConnection in a
@TestConfiguration, so all tests share it and it stops after the
context. Write tests for the repository's custom queries. Then add a
main class in src/test/java that runs the app with the same containers
for local development. Tell me the dependencies to add.

How do you run Spring Boot in production?

10. Expose Actuator safely

The Actuator endpoints docs say "By default, only the health endpoint is exposed over HTTP and JMX," and that endpoints "may contain sensitive information."

Configure Spring Boot Actuator for production. We deploy to
{{platform:Kubernetes}}. Current config:

{{config}}

Expose only the endpoints we need (health, info, metrics or
prometheus), on a separate management port if it suits the platform.
Set up liveness and readiness probes, hide health details from
anonymous users, and secure the rest with Spring Security. Explain
why env, heapdump and beans should stay hidden.

11. Turn on virtual threads

The SpringApplication docs say virtual threads "require Java 21 or later" and that "Java 24 or later is strongly recommended," enabled with spring.threads.virtual.enabled.

We want to turn on virtual threads in our Spring Boot service on Java
{{java_version:25}}. Here is our config and the code that does blocking
I/O:

{{code}}

Tell me what spring.threads.virtual.enabled changes, which of our
thread pool settings will stop having an effect, and whether we need
spring.main.keep-alive. Find code likely to pin virtual threads, such
as long synchronized blocks around I/O, and suggest fixes. Give a plan
to measure throughput and latency before and after.

12. Externalize configuration with @ConfigurationProperties

Our config values are scattered across @Value annotations:

{{code}}

Group them into @ConfigurationProperties records with validation
annotations, sensible defaults and clear names. Show the
application.yml with profiles for {{profiles:dev and prod}}, and keep
secrets out of the file by reading them from environment variables.
Fail at startup with a clear message if a required value is missing.
Add a test that binds the properties.

13. Explain a startup failure

Our Spring Boot app fails to start with this output:

{{log}}

Explain the root cause in plain words, starting from the last "Caused
by" line. Common suspects: missing beans, circular dependencies,
conflicting auto-configuration, a bad property value, or a version
mismatch between Spring Boot and a library. Give the fix, and tell me
how to confirm it with the conditions report (--debug) if
auto-configuration is involved.

Turn your favorite one into a skill

If you run the upgrade or N+1 prompt across many services, make it a skill so Claude Code or Codex applies it when the task matches. Paste the prompt into the free SKILL.md generator to get a valid SKILL.md in your browser. For packaging, the Docker prompts help build small images, and the API design prompts help plan endpoints before you write controllers.

To keep these prompts one shortcut away, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{boot_version:4.1}} stay fillable, and Cmd+K finds any prompt by name or tag.