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

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)

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.