
Springboot Verification
Run a full Maven or Gradle verification loop on a Spring Boot service before you open a PR or push to staging or production.
Overview
Spring Boot Verification is an agent skill most often used in Ship (also Ship review and Ship security) that runs build, static analysis, tests with coverage, and security or diff checks before a Spring Boot PR or deploy
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill springboot-verificationWhat is this skill?
- Four-phase pipeline: build, static analysis (SpotBugs, PMD, Checkstyle), tests with coverage, then security and diff rev
- Maven and Gradle command recipes with parallel `-T 4` builds where applicable
- Stops the loop on first build failure to avoid wasted CI time
- Documents an 80%+ line or branch coverage expectation via JaCoCo reports
- Activated before PRs, after major refactors or dependency upgrades, and pre-deploy
- Four-phase verification pipeline: build, static analysis, tests plus coverage, security and diff review
- Documents 80%+ coverage expectation with JaCoCo
- Supports both Maven `-T 4` and Gradle `check` task families
Adoption & trust: 4.8k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
Who is it for?
Solo builders maintaining Spring Boot APIs who want a scripted pre-PR and pre-deploy checklist aligned with SpotBugs, PMD, Checkstyle, JaCoCo, and test metrics.
Skip if: Greenfield prototypes with no tests yet, non-JVM stacks, or teams that already enforce an identical pipeline exclusively in CI with no local parity needs.
When should I use this skill?
Before opening a pull request for a Spring Boot service, after major refactoring or dependency upgrades, pre-deployment verification, or when validating test coverage thresholds.
What do I get? / Deliverables
You get a stop-on-failure verification sequence with concrete Maven or Gradle commands, test and coverage numbers, and static-analysis results so you only merge or deploy when the full loop passes.
- Pass or fail status for build, analysis, tests, and security steps
- Test pass or fail counts and coverage percentages
- Actionable fix list when any phase fails
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Shipping safely for JVM backends means proving the artifact builds, passes static analysis, meets coverage thresholds, and clears security checks—the canonical home for that gate is the Ship phase. The skill centers on automated tests, JaCoCo-style coverage reporting, and pass or fail metrics, so Testing is the primary shelf even though build and lint steps are included.
Where it fits
Run `mvn test` and JaCoCo reporting to confirm coverage before requesting review on a billing microservice change.
Complete static analysis and diff review steps after a large refactor so reviewers see a green verification log attached to the PR.
Execute the security scan phase in the loop before promoting a Spring Boot build from staging to production.
Re-run the full loop after a production hotfix to ensure dependency upgrades did not regress tests or analysis plugins.
How it compares
Use as a JVM-focused verification workflow instead of generic lint-only or frontend test skills that skip Maven or Gradle assembly gates.
Common Questions / FAQ
Who is springboot-verification for?
It is for solo and indie developers shipping Spring Boot services who need a disciplined build, analysis, test, and security loop before pull requests or deployments.
When should I use springboot-verification?
Use it in Ship when opening a backend PR, after large refactors or dependency upgrades, and again in Ship launch or operate paths when validating staging or production readiness; it also supports Ship review when diff review is part of your gate.
Is springboot-verification safe to install?
It instructs local Maven and Gradle runs and standard analysis plugins; review the Security Audits panel on this Prism page before installing any skill from the catalog.
SKILL.md
READMESKILL.md - Springboot Verification
# Spring Boot Verification Loop Run before PRs, after major changes, and pre-deploy. ## When to Activate - Before opening a pull request for a Spring Boot service - After major refactoring or dependency upgrades - Pre-deployment verification for staging or production - Running full build → lint → test → security scan pipeline - Validating test coverage meets thresholds ## Phase 1: Build ```bash mvn -T 4 clean verify -DskipTests # or ./gradlew clean assemble -x test ``` If build fails, stop and fix. ## Phase 2: Static Analysis Maven (common plugins): ```bash mvn -T 4 spotbugs:check pmd:check checkstyle:check ``` Gradle (if configured): ```bash ./gradlew checkstyleMain pmdMain spotbugsMain ``` ## Phase 3: Tests + Coverage ```bash mvn -T 4 test mvn jacoco:report # verify 80%+ coverage # or ./gradlew test jacocoTestReport ``` Report: - Total tests, passed/failed - Coverage % (lines/branches) ### Unit Tests Test service logic in isolation with mocked dependencies: ```java @ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void createUser_validInput_returnsUser() { var dto = new CreateUserDto("Alice", "alice@example.com"); var expected = new User(1L, "Alice", "alice@example.com"); when(userRepository.save(any(User.class))).thenReturn(expected); var result = userService.create(dto); assertThat(result.name()).isEqualTo("Alice"); verify(userRepository).save(any(User.class)); } @Test void createUser_duplicateEmail_throwsException() { var dto = new CreateUserDto("Alice", "existing@example.com"); when(userRepository.existsByEmail(dto.email())).thenReturn(true); assertThatThrownBy(() -> userService.create(dto)) .isInstanceOf(DuplicateEmailException.class); } } ``` ### Integration Tests with Testcontainers Test against a real database instead of H2: ```java @SpringBootTest @Testcontainers class UserRepositoryIntegrationTest { @Container static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16-alpine") .withDatabaseName("testdb"); @DynamicPropertySource static void configureProperties(DynamicPropertyRegistry registry) { registry.add("spring.datasource.url", postgres::getJdbcUrl); registry.add("spring.datasource.username", postgres::getUsername); registry.add("spring.datasource.password", postgres::getPassword); } @Autowired private UserRepository userRepository; @Test void findByEmail_existingUser_returnsUser() { userRepository.save(new User("Alice", "alice@example.com")); var found = userRepository.findByEmail("alice@example.com"); assertThat(found).isPresent(); assertThat(found.get().getName()).isEqualTo("Alice"); } } ``` ### API Tests with MockMvc Test controller layer with full Spring context: ```java @WebMvcTest(UserController.class) class UserControllerTest { @Autowired private MockMvc mockMvc; @MockBean private UserService userService; @Test void createUser_validInput_returns201() throws Exception { var user = new UserDto(1L, "Alice", "alice@example.com"); when(userService.create(any())).thenReturn(user); mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(""" {"name": "Alice", "email": "alice@example.com"} """)) .andExpect(status().isCreated()) .andExpect(jsonPath("$.name").value("Alice")); } @Test void createUser_invalidEmail_returns400() throws Exception { mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(""" {"name": "Alice", "email": "not-an-em