# Review Spring Boot

> Performs a full enterprise production-readiness review of Spring Boot projects (single- or multi-module) across architecture, Spring/JDK practices, performance, memory, concurrency, data, API, security, resilience, caching, messaging, observability, testing, ops, cloud, quality, and scalability. Auto-detects Spring Boot and JDK versions from the project, lets the user pick which review areas to run, and writes a timestamped report to the project root. Use when the user asks to review a Spring Boot project or backend, requests a production-readiness or enterprise-readiness assessment, or invokes /review-spring-boot.

- Skill: `anarefin/review-spring-boot` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add anarefin/review-spring-boot`
- Raw SKILL.md: https://api.skillmd.com/api/skills/anarefin/review-spring-boot/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: anarefin (https://skillmd.com/u/anarefin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/anarefin/review-spring-boot

---


# Review Spring Boot (Enterprise Production Readiness)

Full-project review skill for Spring Boot applications (single- or multi-module). Spring Boot and JDK versions are detected from the project — never assumed. The review is split into focused area modules; the user selects which areas to run, and the consolidated report is written to a timestamped file in the project root.

Adopt this framing for every module:

> Act as a Principal Software Architect, JVM Performance Engineer, Spring Boot Expert, Security Architect, Distributed Systems Expert, and Production Reliability Engineer, performing an enterprise production readiness assessment for a high-scale, mission-critical application.

## How to run

1. **Step 0 — Detect stack & layout** (before any review module):
   - Read build files to determine the project's actual stack:
     - **Build tool:** `pom.xml` (Maven) or `build.gradle` / `build.gradle.kts` / `settings.gradle` / `settings.gradle.kts` (Gradle).
     - **Spring Boot version:** from `spring-boot-starter-parent`, `org.springframework.boot` plugin, or dependency management BOM.
     - **JDK version:** from `<java.version>` / `<maven.compiler.release>` (Maven), `sourceCompatibility` / Java toolchain (Gradle), or fallback `.java-version` / `.sdkmanrc`.
     - **Language(s):** detect Java, Kotlin, and/or Groovy from source file extensions (`.java` / `.kt` / `.groovy`) and Gradle Kotlin DSL. Every module must scan **all** detected languages — do not assume Java-only.
     - **Layout:** single-module vs multi-module — check `<modules>` in `pom.xml`, `include` in `settings.gradle`, or multiple submodule directories.
     - **Configuration:** locate `application.properties` / `application.yml` / `application-*.yml|properties` and the active profiles. Config files are in-scope for every review area.
   - **Guardrail — is this even a Spring Boot project?** If no Spring Boot build file is found (no `spring-boot-starter-*`, no `org.springframework.boot` plugin or BOM), STOP and report *"Not a Spring Boot project — nothing to review."* Do the same if the target path is empty or unreadable. Do not fabricate findings.
   - If any version cannot be determined, state that explicitly. Do not assume defaults.
   - **Project inventory:** build a lightweight inventory before running any module — controllers, services, repositories, entities, configuration files, and the module list. This anchors the review and prevents missed areas on large repos.
   - Record all detected values; use them in every review framing and recommendation.

2. **Step 1 — Ask which areas to review.** After Step 0, print the 8 review areas as a **numbered text list** (numbers and names from the Review areas table below) and ask the user to **reply with the numbers** of the areas to run — e.g. `1 2 7`. Accept `all` as a shortcut for every area. Multiple selection is expected. Do **not** use `AskUserQuestion` for this — there are more areas than it can present. There is **no preset default**: do not pre-select or auto-pick any subset — print the list, then **wait for the user's reply** before running anything. Only the selected areas execute; the final report (module 09) always runs. Record the selection so the report can list which areas ran and which were skipped.

   Present exactly this list:

   ```
   Which areas should I review? Reply with the numbers (e.g. 1 2 7), or "all".

   1. Architecture & Design
   2. Spring Boot & JDK
   3. Performance & Runtime
   4. Data & API
   5. Security & Resilience
   6. Observability & Testing
   7. Ops, Cloud & Build
   8. Quality & Scalability
   ```

3. **Step 2 — Run the selected area modules.**
   - **Run strategy:** for large projects, dispatch the selected areas as **parallel subagents** (one per module), each given the Step 0 detected stack + inventory, each returning findings in the standard output format. For small projects or a single selected area, running inline/sequentially is fine. State which mode was used.
   - Scan the **entire project** for each selected area — every module, package, source language, and configuration file — whether single- or multi-module.

4. **Step 3 — Always run** `modules/09-final-report.md` last to produce the consolidated Review + Fix report and **write it to a timestamped file** (see below).

## Review areas

| # | Area | Covers sections | Load |
|---|------|-----------------|------|
| 1 | Architecture & Design | 1 Architecture, 2 Multi-Module, 5 SOLID, 6 OO Design, 7 Design Patterns | `modules/01-architecture-design.md` |
| 2 | Spring Boot & JDK | 3 Spring Boot, 4 JDK | `modules/02-spring-jdk.md` |
| 3 | Performance & Runtime | 8 Performance, 9 Memory, 10 GC, 11 Concurrency | `modules/03-performance-runtime.md` |
| 4 | Data & API | 12 Database, 13 API Design | `modules/04-data-api.md` |
| 5 | Security & Resilience | 14 Security, 15 Resilience, 16 Caching, 17 Messaging | `modules/05-security-resilience.md` |
| 6 | Observability & Testing | 18 Logging, 19 Observability, 20 Testing, 21 Configuration | `modules/06-observability-testing.md` |
| 7 | Ops, Cloud & Build | 22 Docker/K8s, 23 Cloud, 24 Production, 26 Dependencies, 27 Build | `modules/07-ops-cloud-build.md` |
| 8 | Quality & Scalability | 25 Code Quality, 28 Maintainability, 29 Scalability | `modules/08-quality-scalability.md` |
| 9 | Final Report (always runs) | Consolidated findings and prioritized fix list | `modules/09-final-report.md` |

## Global rules (apply to every module)

Do not make assumptions. If information is missing, explicitly state what additional code, configuration, infrastructure, or documentation is needed before reaching a conclusion.

Be evidence-driven: reference the specific code or configuration that supports each finding, distinguish confirmed issues from potential risks, and avoid speculative recommendations.

**Reproducibility:** findings must be evidence-only (cite file + line/method), free of speculation, and deterministically ordered. Identical inputs should yield the same report on re-run.

### Severity definitions (assign severity consistently)

| Severity | Meaning |
|----------|---------|
| **Critical** | Production outage, data loss, or security breach — exploitable/triggerable now. Fix before anything ships. |
| **High** | Serious risk under load or likely to cause incidents. Fix before release. |
| **Medium** | Meaningful weakness that degrades reliability, security, or maintainability. Schedule soon. |
| **Low** | Minor, stylistic, or best-practice nit. |

### Output format

For every issue identified, use this structure (describe only; do not edit project code):

```
### [ID] [Severity] Short title
- Location: `path/File.{java|kt}` (Class#method) — Module: <name> (include only if multi-module)
- Review: what's wrong and why it's a production risk (evidence-based, 1-3 sentences)
- Fix: the concrete recommended change; include a code snippet when it clarifies
```

- **ID** is a stable, area-prefixed identifier: `<AREA>-NNN` — e.g. `ARCH-001`, `PERF-003`, `SEC-002`, `DATA-004`, `OBS-001`, `OPS-002`, `QUAL-001`. It is used to cross-link the Findings section and the Prioritized Fix List in the final report.
- **Severity** is one of Critical / High / Medium / Low, per the definitions above.

### Report file

The consolidated final report is **written to a file**, not just printed:

- Path: `reviews/spring-boot-review-{YYYY-MM-DD-HHMM}.md`, relative to the **project root**.
- Create the `reviews/` directory if it does not exist. Derive the timestamp from the current date-time. **Never overwrite** a prior run — each run produces a new timestamped file.
- After writing, print a short summary (counts + verdict) and the report file path to chat.