creating-springboot-projects — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited creating-springboot-projects (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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/.
references/java-version-policy.md before you pick a newer, non-LTS Java.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.
Pick the generator:
command -v progen. Read references/progen-integration.md before you use it, and run it with JDK 25: on JDK 27 its output doesn't compile. Progen deletes ./<app-name>/ if it exists, so always run it through scripts/progen_config.py, which validates values and refuses to overwrite.For Spring Initializr, capture the baseline:
references/java-version-policy.md.Baseline dependencies for most projects:
Optional dependencies based on architecture or features:
CodeRulesTests, Step 6) for every projectRead 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. If progen generated the project, skip the assets it already covers (see references/progen-integration.md).
#### Placeholder convention
Every template uses {{TOKEN}} placeholders. Resolve all of them before applying. The 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}}. A legacy variant, used 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 explicitlyMaven projects get the shared agent setup from the spring-boot-team-harness skill: AGENTS.md, .claude/settings.json with its hooks, project skills, the ./mvnw verify gates, and a CI workflow. Its CodeRulesTests is the project's architecture test: ArchUnit rules for proxied methods called from their own class, controllers that start transactions, use repositories or expose entities, @Retryable that nothing switches on, @Autowired fields, System.out, Jackson 2 and disabled tests. BuildSetupTests checks the pom and properties. Pass --no-modules for layered and ddd-hexagonal, whose subpackages are layers, not modules:
python3 "${CLAUDE_SKILL_DIR}/../spring-boot-team-harness/scripts/apply_harness.py" /path/to/project [--no-modules]${CLAUDE_SKILL_DIR} is this skill's folder. Codex doesn't set it, so there use the folder this SKILL.md is in.
On a progen project, it keeps what progen already set up (Spotless, Spring Modulith, ModularityTests, ArchUnitTests, AGENTS.md) and adds only what's missing. See references/progen-integration.md for the ArchUnitTests rules that conflict with some architectures. Then run ./mvnw spotless:apply and ./mvnw verify. Expect NullAway to flag progen methods that return null without @Nullable: annotate them and handle the null at the callers. Then draft the Modules, Run and test and Team conventions sections of AGENTS.md from the code, as the harness skill's step 4 describes, and go through them with the user.
The harness supports Maven only. For a Gradle project, copy ../spring-boot-team-harness/assets/tests/CodeRulesTests.java to src/test/java/<package>/CodeRulesTests.java, replace {{TEST_PACKAGE}} and {{BASE_PACKAGE}} with the base package, and add testImplementation 'com.tngtech.archunit:archunit:1.5.1'.
For ddd-hexagonal, also add the onionArchitecture() test from assets/pom-additions.xml.
Fix every FAIL before you hand the project over:
python3 "${CLAUDE_SKILL_DIR}/scripts/check_new_project.py" /path/to/projectIt fails on unresolved {{PLACEHOLDER}} tokens, a Spring Boot version before 4.x, a missing ArchUnit test or dependency, and Boot 3 starter or Testcontainers 1 names. It warns on an older 4.x line and on H2. Then run the build (./mvnw verify or ./gradlew build).
springboot-migration for upgrades of existing applications rather than new-project setup.writing-springboot-tests for tests at the service's edges (HTTP clients, messaging, published events): it has verified Boot 4 templates and the traps that make such tests pass without proving anything.references/architecture-guide.mdreferences/spring-boot-4-features.mdreferences/java-version-policy.mdreferences/progen-integration.mdscripts/progen_config.py: builds and validates .progen.json, and runs progen with --run.scripts/check_new_project.py: checks the finished project against this skill (Step 7). Exit 1 means at least one failure.When the user asks for a plan or scaffold recommendation, return:
## Recommended architecture
- Pattern:
- Why:
## Initial setup
- Generator: progen or Spring Initializr
- Build tool:
- Java version:
- Spring Boot version:
- Core dependencies:
## Assets to apply
- `assets/...`
## Next implementation steps
1. ...
2. ...
3. ...~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.