$npx -y skills add a-pavithraa/springboot-skills-marketplace --skill creating-springboot-projectsCreates Java 25 and Spring Boot 4 project structures, scaffolds, and implementation starting points for new services, REST APIs, and modular backends. Use when the task is to initialize a Spring Boot project, choose an architecture, select Spring Boot 4 features, or apply the bun
| 1 | # Creating Spring Boot Projects |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | 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/`. |
| 6 | |
| 7 | ## Critical rules |
| 8 | |
| 9 | - Never jump straight to implementation before assessing project complexity. |
| 10 | - Default to the simplest architecture that fits the domain. |
| 11 | - Treat Java 25 and Spring Boot 4 as the target stack for this skill. |
| 12 | - Read the reference files before choosing a higher-complexity architecture or optional framework feature. |
| 13 | - Reuse the templates in `assets/` instead of rewriting the same scaffolding from scratch. |
| 14 | |
| 15 | ## Workflow |
| 16 | |
| 17 | ### Step 1: Assess project shape |
| 18 | |
| 19 | Collect the project constraints first: |
| 20 | |
| 21 | 1. Domain complexity: simple CRUD, moderate workflow, or rich domain rules. |
| 22 | 2. Team size: 1-3, 3-10, or 10+. |
| 23 | 3. Expected lifespan: months, 1-2 years, or 5+ years. |
| 24 | 4. Type-safety needs: basic validation or strong value-object-heavy modeling. |
| 25 | 5. Bounded contexts: single domain or multiple feature areas. |
| 26 | 6. Persistence and infrastructure needs: database choice, migration tool, local development setup. |
| 27 | |
| 28 | ### Step 2: Choose the architecture |
| 29 | |
| 30 | Use this matrix as the default decision aid. If the choice is not obvious, read `references/architecture-guide.md` before proceeding. |
| 31 | |
| 32 | | Pattern | Use when | Complexity | |
| 33 | |---------|----------|------------| |
| 34 | | `layered` | CRUD services, prototypes, MVPs | Low | |
| 35 | | `package-by-module` | 3-5 distinct features with moderate growth | Low-Medium | |
| 36 | | `modular-monolith` | Module boundaries matter and Spring Modulith is justified | Medium | |
| 37 | | `tomato` | Rich domain modeling, value objects, stronger type safety | Medium-High | |
| 38 | | `ddd-hexagonal` | Complex domains, CQRS, strong infrastructure isolation | High | |
| 39 | |
| 40 | ### Step 3: Define the initial Boot 4 setup |
| 41 | |
| 42 | Use Spring Initializr and capture the baseline: |
| 43 | |
| 44 | - Project: Maven or Gradle |
| 45 | - Language: Java |
| 46 | - Spring Boot: 4.0.x |
| 47 | - Java: 25 |
| 48 | |
| 49 | Baseline dependencies for most projects: |
| 50 | |
| 51 | - Spring Web MVC |
| 52 | - Validation |
| 53 | - Spring Data JPA if persistence is required |
| 54 | - Flyway or Liquibase |
| 55 | - database driver |
| 56 | - Spring Boot Actuator |
| 57 | - Testcontainers for integration tests |
| 58 | |
| 59 | Optional dependencies based on architecture or features: |
| 60 | |
| 61 | - Spring Modulith for modular monolith or tomato designs |
| 62 | - ArchUnit for stronger architecture enforcement |
| 63 | - Additional Spring Boot 4 features only when the use case needs them |
| 64 | |
| 65 | Read `references/spring-boot-4-features.md` before selecting: |
| 66 | |
| 67 | - RestTestClient |
| 68 | - HTTP Service Clients |
| 69 | - API versioning |
| 70 | - JSpecify null-safety |
| 71 | - resilience features |
| 72 | |
| 73 | ### Step 4: Apply the matching assets |
| 74 | |
| 75 | Use the bundled templates from `assets/` and replace placeholders only after the package and module names are settled. |
| 76 | |
| 77 | Core project templates: |
| 78 | |
| 79 | - `assets/controller.java` |
| 80 | - `assets/repository.java` |
| 81 | - `assets/rich-entity.java` |
| 82 | - `assets/value-object.java` |
| 83 | - `assets/service-cqrs.java` |
| 84 | - `assets/exception-handler.java` |
| 85 | - `assets/flyway-migration.sql` |
| 86 | - `assets/docker-compose.yml` |
| 87 | |
| 88 | Boot 4 and modularity templates: |
| 89 | |
| 90 | - `assets/http-service-client.java` |
| 91 | - `assets/api-versioning-config.java` |
| 92 | - `assets/resttestclient-test.java` |
| 93 | - `assets/package-info-jspecify.java` |
| 94 | - `assets/modularity-test.java` |
| 95 | - `assets/resilience-service.java` |
| 96 | - `assets/pom-additions.xml` |
| 97 | - `assets/testcontainers-test.java` |
| 98 | |
| 99 | ### Step 5: Fill in architecture-specific pieces |
| 100 | |
| 101 | Read `references/architecture-guide.md` for package structure and apply the matching templates: |
| 102 | |
| 103 | - `layered`: keep modules simple and avoid premature DDD abstractions |
| 104 | - `package-by-module`: group by feature and keep shared code minimal |
| 105 | - `modular-monolith`: add Modulith verification and explicit module APIs |
| 106 | - `tomato`: add value objects and rich domain entities where they protect important invariants |
| 107 | - `ddd-hexagonal`: separate application, domain, and infrastructure explicitly |
| 108 | |
| 109 | ### Step 6: Hand off specialized concerns when needed |
| 110 | |
| 111 | - Use `spring-data-jpa` when the user needs deeper query, projection, repository, or relationship decisions. |
| 112 | - Use `springboot-migration` for upgrades of existing applications rather than new-project setup. |
| 113 | |
| 114 | ## Reference loading guide |
| 115 | |
| 116 | - Package structures, anti-patterns, and upgrade paths: `references/architecture-guide.md` |
| 117 | - Spring Boot 4 feature-specific guidance: `references/spring-boot-4-features.md` |
| 118 | |
| 119 | ## Output format |
| 120 | |
| 121 | When the user asks for a plan or scaffold recommendation, return: |
| 122 | |
| 123 | ```markdown |
| 124 | ## Recommended architecture |