Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →rrezartprebreza/spring-modulith
Use when organizing or verifying a modular Spring Boot monolith with Spring Modulith, including module APIs, dependency rules and reliable module events. Do not restructure an application into modules for an unrelated endpoint change.
Passed 21 of 23 test cases with the skill, and 13 of 23 without it.
and 9 more in the full report
8 fixed13 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
In our Spring Boot app, when an order is created, an email notification must be sent. We want the listener to execute asynchronously and only after the primary database transaction successfully commits. What annotation should be placed on the listener method?
| Checked | Without skill | With skill |
|---|---|---|
| The response specifies placing @ApplicationModuleListener on the event handler method. | Missed | Passed |
The instructions your model reads when the skill loads.
Use the Spring Modulith 2.x line matching the exact Boot 4 minor; do not import a Boot 3 Modulith 1.x BOM.
Inspect the application root package, module boundaries and current dependency graph. Use direct subpackages as modules; keep their API at the module root and implementation in internal subpackages. Expose a named interface only for an intentional shared API. Use allowedDependencies when the architecture needs explicit dependency constraints. Avoid creating a generic shared module that every feature depends on.
Add spring-modulith-starter-test with test scope and run ApplicationModules.of(Application.class).verify() in CI. It checks cycles and access to module internals. Add ApplicationModuleTest for behavior confined to a module. A passing structure check does not prove transactional or delivery correctness.
See good module verification and bad cross-module dependency.
Publish immutable event payloads containing IDs and necessary facts, not managed JPA entities. Use ApplicationModuleListener for asynchronous transactional listeners when that timing fits. For delivery that must survive a process crash, configure a persistent event publication registry using the chosen JDBC/JPA starter and manage its schema through migrations. An in-memory registry and a plain after-commit callback are not durable delivery.
Make handlers idempotent: a crash after the business effect but before recording completion can cause redelivery. Define retry/republication and retention explicitly, and test failed listeners and application restarts. For external brokers, use supported event externalization with persistent publication tracking; do not promise end-to-end exactly-once processing.
test cases passed, vs 13 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.