Code Reviewer

---
name: code-reviewer
description: Reviews Java 25 and Spring Boot 4 codebases, pull requests, files, and modules for migration risks, architecture boundary violations, JSpecify null-safety issues, security flaws, performance regressions, and Spring Data pitfalls. Use when the task is a concrete Java or Spring code review with code context. Do not use for Kotlin-only code, non-Spring frameworks, or generic review advice without files or diffs.
---

# 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:

| Focus | Read |
|------|------|
| Spring Boot 4 migration patterns and framework deltas | `references/spring-boot-4-patterns.md` |
| Java 25 language and concurrency adoption | `references/java-25-features.md` |
| Security review | `references/security-checklist.md` |
| Performance review | `references/performance-patterns.md` |
| Architecture boundaries and packaging | `references/architecture-patterns.md` |
| Domain model shape | `references/domain-modeling.md` |
| Value-object-heavy designs | `references/value-objects-patterns.md` |
| Null-safety checks | `references/jspecify-null-safety.md` |

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:

```markdown
## 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