smithery.ai
Use when starting a new Spring Boot 4 project — scaffolding a service, REST API, or modular backend; picking an architecture (layered, package-by-module, modular-monolith, tomato, DDD-hexagonal); selecting Spring Boot 4 features; or applying the bundled templates and references in this skill.
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Get best practices for developing applications with Spring Boot.
19.9K installsGet best practices for developing applications with Spring Boot and Kotlin.
9.8K installsSpring Boot architecture patterns, REST API design, layered services, data access, caching, asy…
11.2K installsSpring Security best practices for authn/authz, validation, CSRF, secrets, headers, rate limiti…
10K installsTest-driven development for Spring Boot using JUnit 5, Mockito, MockMvc, Testcontainers, and Ja…
9.4K installsVerification loop for Spring Boot projects: build, static analysis, tests with coverage, securi…
8.7K installsOther skills from smithery.ai · top by installs.
npx skills add https://smithery.ai
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Files included with this skill beyond the listing page.
SKILL.md
7,358 B
SUMMARY.md
672 B
Use this skill to create new Spring Boot 4 projects or define their structure before implementation. The skill adds value when the user needs an architecture decision, Spring Boot 4 feature selection, or the bundled templates in assets/.
assets/ instead of rewriting the same scaffolding from scratch.Collect the project constraints first:
Use this matrix as the default decision aid. If the choice is not obvious, read references/architecture-guide.md before proceeding.
| Pattern | Use when | Complexity |
|---|---|---|
layered |
CRUD services, prototypes, MVPs | Low |
package-by-module |
3-5 distinct features with moderate growth | Low-Medium |
modular-monolith |
Module boundaries matter and Spring Modulith is justified | Medium |
tomato |
Rich domain modeling, value objects, stronger type safety | Medium-High |
ddd-hexagonal |
Complex domains, CQRS, strong infrastructure isolation | High |
tomatois a value-object-heavy modular monolith: JPA entities embed VOs, validation lives in VO constructors, and Spring converters bind VOs at the request boundary. Seereferences/architecture-guide.mdfor the full definition.
Use Spring Initializr and capture the baseline:
Baseline dependencies for most projects:
Optional dependencies based on architecture or features:
Read references/spring-boot-4-features.md before selecting:
Use the bundled templates from assets/ and replace placeholders only after the package and module names are settled.
Every template uses {{TOKEN}} placeholders. Resolve all of them before applying — templates do not compile until every placeholder is replaced. The full set used across assets/:
| Placeholder | Replace with | Example |
|---|---|---|
{{PACKAGE}} |
Base Java package | com.acme.shop |
{{MODULE}} |
Feature/module name (lowercase) | orders |
{{NAME}} |
Domain type name (PascalCase) | Order, ProductSKU |
{{TYPE}} |
Wrapped scalar type inside a value object | String, Long, BigDecimal |
{{FIELD}} |
Record field name (camelCase) | code, amount |
{{TABLE_NAME}} |
Database table name (used in JPA @Table) |
orders |
{{TABLE}} |
Same meaning as {{TABLE_NAME}} — legacy variant kept only in flyway-migration.sql |
orders |
{{PROJECT_NAME}} |
Project artifactId / docker prefix (used only in docker-compose.yml) |
shop-api |
{{name}} |
HTTP service group identifier — not a lowercase variant of {{NAME}}. Appears only in commented @ImportHttpServices(group = "...") examples. |
orders |
If a template uses a placeholder not listed here, treat it as a typo and confirm the intended value before applying.
Core project templates:
assets/controller.javaassets/repository.javaassets/base-entity.javaassets/rich-entity.javaassets/value-object.javaassets/spring-converter.javaassets/service-cqrs.javaassets/exception-handler.javaassets/flyway-migration.sqlassets/docker-compose.ymlBoot 4 and modularity templates:
assets/http-service-client.javaassets/api-versioning-config.javaassets/resttestclient-test.javaassets/package-info-jspecify.javaassets/modularity-test.javaassets/resilience-service.javaassets/pom-additions.xmlassets/testcontainers-test.javaRead references/architecture-guide.md for package structure and apply the matching templates:
layered: keep modules simple and avoid premature DDD abstractionspackage-by-module: group by feature and keep shared code minimalmodular-monolith: add Modulith verification and explicit module APIstomato: add value objects and rich domain entities where they protect important invariantsddd-hexagonal: separate application, domain, and infrastructure explicitlyspring-data-jpa when the user needs deeper query, projection, repository, or relationship decisions.springboot-migration for upgrades of existing applications rather than new-project setup.references/architecture-guide.mdreferences/spring-boot-4-features.mdWhen the user asks for a plan or scaffold recommendation, return:
## Recommended architecture
- Pattern:
- Why:
## Initial setup
- Build tool:
- Java version:
- Spring Boot version:
- Core dependencies:
## Assets to apply
- `assets/...`
## Next implementation steps
1. ...
2. ...
3. ...