Java 25 and Spring Boot 4 Reviewer

Purpose

Use this skill to run a structured review of Java 25 and Spring Boot 4 code. Keep findings grounded in the actual codebase and use the reference files only for the focus areas that apply.

Critical rules

• Never review without code context. Ask for files, diffs, or the relevant module if none is provided.
• Always cite file paths and line numbers for findings.
• Treat Java 25 and Spring Boot 4 as the target baseline unless the build files show otherwise.
• Analyze workload before recommending virtual threads, reactive rewrites, or architecture changes.
• Use JSpecify as the preferred null-safety baseline for new Boot 4 code, but confirm whether the codebase is still in transition before flagging every legacy annotation.
• Prefer official Spring and Java guidance when a claim depends on framework behavior.

Workflow

Step 1: Confirm scope

Collect the minimum context required to review accurately:

1. Scope: single file, module, PR, or full codebase.
2. Target versions: confirm Java and Spring Boot versions from the build files when relevant.
3. Focus areas: migration, architecture, data access, security, performance, null-safety, or all.
4. Testing context: whether the user expects review findings only or also fix suggestions and test impact.

Step 2: Load only the references that match the review

Load references just in time:

Escalate to another skill when needed:

• Use spring-data-jpa for deep repository, query, and relationship work.
• Use springboot-migration for phased upgrade planning or upgrade execution.

Step 3: Run the review passes

Run only the passes that match the request. For a full review, use this order.

Pass A: Build and configuration

• Verify Java and Spring Boot versions in pom.xml or build.gradle.
• Check starter names and migration leftovers.
• Scan for Jackson 3 migration issues, outdated test annotations, and version drift.

Pass B: API correctness

• Check controller and service boundaries.
• Check validation and error handling.
• Check nullability in public APIs and method overrides.

Pass C: Architecture and packaging

• Identify the architecture style in use.
• Verify package structure is consistent with that style.
• Flag boundary leaks such as controller-to-repository shortcuts or infrastructure types in domain code.

Pass D: Data access

• Check repository placement and aggregate boundaries.
• Check for N+1 queries, missing pagination, projection mismatches, and transaction misuse.

Pass E: Security

• Check authentication and authorization.
• Check input validation and unsafe query patterns.
• Check secrets handling and sensitive logging.

Pass F: Performance and resilience

• Check caching strategy, unbounded reads, async usage, and remote call behavior.
• Evaluate virtual-thread usage only when the code and workload justify it.
• Check timeouts, retries, and connection-pool assumptions.

Quick triggers for findings

Use these as review prompts, not as a substitute for code evidence.

Spring Boot 4 and migration

• old starter names
• old Mockito test annotations
• Jackson 2 assumptions in a Boot 4 codebase
• TestRestTemplate usage instead of RestTestClient
• manual HttpServiceProxyFactory boilerplate instead of @ImportHttpServices
• custom API versioning instead of native spring.mvc.apiversion.*
• @ConcurrencyLimit or native @Retryable without @EnableResilientMethods

Null-safety

• missing package-info.java where the project uses JSpecify
• lingering org.springframework.lang annotations in code that has already moved to JSpecify
• missing copied nullability annotations on overrides

Architecture

• controllers calling repositories directly
• JPA entities exposed in APIs
• modulith boundary leaks
• business logic concentrated in controllers

Performance

• entity traversal in loops
• missing pagination
• projection opportunities ignored on read-heavy paths
• virtual-thread recommendations with no workload evidence

Security

• missing authorization on privileged actions
• SQL or NoSQL injection risk
• secrets in source or logs
• unsafe error exposure

Report format

Order findings by severity and use this template:

## Critical
- **[Category]**: Issue summary
  - **File**: `path/to/File.java:123`
  - **Impact**: What can fail, leak, or regress
  - **Fix**: Specific change to make

## High
- ...

## Medium
- ...

## Low
- ...

If there are no findings, say so explicitly and call out any remaining blind spots such as unreviewed modules, missing tests, or unavailable runtime context.

Common review modes

Quick PR review

1. Read the changed files.
2. Load references/spring-boot-4-patterns.md and references/java-25-features.md.
3. Add references/security-checklist.md or references/performance-patterns.md if the diff touches those areas.
4. Report only concrete findings with file and line references.

Security review

1. Read references/security-checklist.md.
2. Focus on controllers, service entry points, security configuration, and persistence boundaries.
3. Report exploitability and affected entry points, not just the violated rule.

Architecture review

1. Read references/architecture-patterns.md.
2. Add references/domain-modeling.md or references/value-objects-patterns.md if the code suggests a rich-domain approach.
3. Report boundary mismatches and coupling problems tied to the current architecture style.

Migration review

1. Read references/spring-boot-4-patterns.md and references/java-25-features.md.
2. Focus on migration leftovers, outdated APIs, and partial adoption problems.
3. Use springboot-migration if the user wants a phased upgrade plan rather than a review.

When not to use this skill

• Kotlin-first codebases
• Non-Spring Java frameworks such as Micronaut or Quarkus
• Generic review coaching without code context
• Frontend-only changes