plinth

Use when you need to add or configure Maven plugins in your pom.xml — including quality tools (enforcer, surefire, failsafe, jacoco, pitest, spotbugs, pmd), security scanning (OWASP), code formatting (Spotless), version management, container image build (Jib), build information tracking, and benchmarking (JMH) — through a consultative, modular step-by-step approach that only adds what you actually need. This should trigger for requests such as Add Maven plugins in pom.xml; Improve Maven plugins in pom.xml; Configure Maven quality plugins in pom.xml; Add Maven build lifecycle plugins for Java verification; Review Maven plugin versions and executions. Part of Plinth Toolkit

Use when you need to design, review, or improve validation in Spring Boot applications — including Bean Validation on request DTOs, @Valid/@Validated at API boundaries, constraint groups, custom constraints, @ConfigurationProperties validation, nested DTO validation, and consistent validation error handling. This should trigger for requests such as Add validation support in Spring Boot; Review Spring Boot validation rules; Improve request validation in Spring Boot REST APIs; Add custom Bean Validation constraints in Spring Boot; Validate configuration properties in Spring Boot. Part of Plinth Toolkit

Use when a sanitized issue summary, requirement summary, or design brief needs technical design exploration before creating ADRs, specifications, or implementation plans. This skill inspects repository context, clarifies material ambiguity, compares feasible approaches and trade-offs, recommends a direction, obtains approval, and identifies ADR candidates. This should trigger for requests such as Explore a design; Compare implementation approaches; Recommend an architecture direction; Clarify technical options before planning. Part of Plinth Toolkit

Use when building or reviewing Micronaut applications — Micronaut.run bootstrap, @Singleton/@Prototype, @Factory beans, @ConfigurationProperties, environments, @Requires, @Controller vs services, @Scheduled, graceful shutdown, @ExecuteOn for blocking work, and Jakarta-consistent APIs. This should trigger for requests such as Review Java code for Micronaut application structure and beans; Apply best practices for Micronaut configuration, @Requires, and factories; Improve scheduling, shutdown, or threading in Micronaut services. ; Review Micronaut dependency injection scopes and factories; Configure Micronaut @Requires conditions for environments. Part of Plinth Toolkit

Use when you need to apply data-oriented programming best practices in Java — including separating code (behavior) from data structures using records, designing immutable data with pure transformation functions, keeping data flat and denormalized with ID-based references, starting with generic data structures converting to specific types when needed, ensuring data integrity through pure validation functions, and creating flexible generic data access layers. This should trigger for requests such as Improve the code with Data-Oriented Programming; Apply Data-Oriented Programming; Refactor the code with Data-Oriented Programming; Model Java data with records and pure functions; Separate Java behavior from immutable data structures; Validate data integrity with pure Java functions. Part of Plinth Toolkit

Use when you need to write unit tests for Spring Boot applications — including pure unit tests with @ExtendWith(MockitoExtension.class) for @Service/@Component, slice tests with @WebMvcTest and @MockitoBean for controllers, @JsonTest for JSON serialization, parameterized tests with @CsvSource/@MethodSource, test profiles, and @TestConfiguration. For framework-agnostic Java use @131-java-testing-unit-testing. For integration tests use @322-frameworks-spring-boot-testing-integration-tests. This should trigger for requests such as Review Java code for Spring Boot unit tests; Apply best practices for Spring Boot unit tests in Java code; Write Mockito-first unit tests for Spring Boot services; Avoid unnecessary @SpringBootTest in Spring unit tests; Review Spring Boot slice-free unit test design. Part of Plinth Toolkit

Use when you need to create a new Maven-based Micronaut 4.x project using SDKMAN-managed Java and Micronaut CLI tooling. This should trigger for requests such as Create a Micronaut Maven project; Bootstrap Micronaut project with SDKMAN; Generate a new Micronaut service; Create Micronaut 4 Maven project; Scaffold Micronaut service with Java 25. Part of Plinth Toolkit

Use when you need to implement acceptance tests from maintainer-sanitized Gherkin scenario facts for framework-agnostic Java (no Spring Boot, Quarkus, Micronaut) — confirming @acceptance scenarios before coding, happy path with RestAssured, DB/Kafka test fixtures, WireMock for external REST only, and *AT classes run by Failsafe. This should trigger for requests such as Review Java code for acceptance tests; Apply best practices for acceptance tests in Java code; Implement acceptance tests from Gherkin scenarios in Java; Map feature files to Java step definitions; Review Cucumber acceptance tests for Java services. Part of Plinth Toolkit

Use when you need to generate an AGENTS.md file for a Java repository — covering project conventions, tech stack, file structure, commands, Git workflow, and contributor boundaries — through a modular, step-based interactive process that adapts to your specific project needs. This should trigger for requests such as Create AGENTS.md; Update AGENTS.md file; Add agent instructions; Generate contributor instructions for Java agents; Document repository conventions in AGENTS.md. Part of Plinth Toolkit

Use when you need to write unit tests for Micronaut applications — Mockito-first with @ExtendWith(MockitoExtension.class), @MicronautTest with @MockBean, HttpClient @Client(/) assertions, @Property overrides, @ParameterizedTest, and *Test vs *IT naming. For framework-agnostic Java use @131-java-testing-unit-testing. This should trigger for requests such as Add or improve unit tests in a Micronaut project; Reduce unnecessary @MicronautTest usage with Mockito-first tests; Write Mockito-first unit tests for Micronaut services; Mock Micronaut bean collaborators in unit tests; Review fast Micronaut tests without application context. Part of Plinth Toolkit

Use when you need data access with Micronaut Data — @MappedEntity, CrudRepository/PageableRepository, @Query with parameters, @Transactional services, projections, @Version, and @MicronautTest with TestPropertyProvider and Testcontainers. For raw java.sql access without generated repositories, use @511-frameworks-micronaut-jdbc. This should trigger for requests such as Review or implement Micronaut Data repositories and entities; Add transactions, pagination, or projections in Micronaut persistence layer; Model Micronaut Data entities and repositories; Review Micronaut Data transactions and pageable queries; Improve projections or optimistic locking with Micronaut Data. Part of Plinth Toolkit

Use when you need to implement or improve Java logging and observability — including selecting SLF4J with Logback/Log4j2, applying proper log levels (ERROR, WARN, INFO, DEBUG, TRACE), parameterized logging, correlation context, secure logging without sensitive data exposure, environment-specific configuration, log aggregation, monitoring, and alerting. This should trigger for requests such as Improve logging; Apply logging; Refactor logging; Add logging support; Review SLF4J structured logging in Java code. Part of Plinth Toolkit

Use when you need to design or implement Kafka messaging in Spring Boot — including topic design, producer/consumer implementation, JSON serialization with Boot factory customizers, Testcontainers `@ServiceConnection` integration tests, retries and dead-letter topics, idempotency, and error handling. This should trigger for requests such as Add Kafka in Spring Boot; Review Spring Kafka consumers; Improve retries and DLT in Spring Kafka; Configure Spring Kafka topics serializers or listener containers; Add Spring Kafka dead-letter topic handling. Part of Plinth Toolkit

Use when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review breaking changes in this spec; Check compatibility risks; Avoid breaking changes in this OpenSpec change; Review migration impact before release; Assess command and skill compatibility. Part of Plinth Toolkit

Use when you need to write or improve integration tests for Quarkus — including @QuarkusTest, Dev Services for automatic container provisioning, Testcontainers via QuarkusTestResourceLifecycleManager, WireMock for external HTTP stubs, @QuarkusIntegrationTest for black-box testing against packaged artifacts, REST Assured, data isolation strategies (@TestTransaction vs @BeforeEach cleanup), and Maven Surefire/Failsafe three-tier split (*Test, *IT, *AT). This should trigger for requests such as Add or improve integration tests in a Quarkus project; Configure Testcontainers or Dev Services for Quarkus tests; Add WireMock stubs for external HTTP dependencies in Quarkus integration tests; Set up @QuarkusIntegrationTest for packaged artifact or native binary testing; Fix test data isolation or configure Maven Surefire/Failsafe split. Part of Plinth Toolkit

Use when you need to create a DEVELOPER.md file for a Maven project — combining a fixed base template with dynamic sections derived from allowlisted Maven POM structure, including a Plugin Goals Reference, Maven Profiles table, and Submodules table for multi-module projects. This should trigger for requests such as Create DEVELOPER.md; Generate DEVELOPER.md; Maven project documentation; Add Maven documentation; Plugin goals reference. Part of Plinth Toolkit

Use when you need to set up Gatling performance testing for a Java Maven project — including adding Gatling dependencies and the Gatling Maven plugin, creating Java simulations, running gatling:test, configuring a simulation class, and reviewing generated reports. This should trigger for requests such as Add Gatling performance testing; Apply Gatling performance testing; Create a Gatling simulation; Add Gatling support; Review Gatling performance test assertions and feeders. Part of Plinth Toolkit

Use when you need to generate Java project diagrams — including UML sequence diagrams, UML class diagrams, C4 model diagrams, UML state machine diagrams, UML Deployment Diagrams, ER (Entity Relationship) diagrams, and bounded-context diagrams — through a modular, step-based interactive process that adapts to your specific visualization needs. This should trigger for requests such as Generate UML diagram; Create sequence diagram; Create class diagram; Create state machine diagram; Create deployment diagram; Create C4 diagram; Create bounded-context diagram; Create context-map diagram. Part of Plinth Toolkit

Use when you need to add or review Mongock MongoDB data migrations in a Spring Boot application — including Maven coordinates, Spring Data MongoDB drivers, migration scan packages, @ChangeUnit classes, lock/transaction settings, and optional policy-approved MongoDB integration verification. This should trigger for requests such as Add Mongock migrations in Spring Boot; Review Spring MongoDB data migrations; Configure Mongock change units for Spring Data MongoDB; Create Mongock change units for Spring Boot MongoDB; Review Mongock migration ordering in a Spring service. Part of Plinth Toolkit

Use when you need to apply functional programming principles in Java — including writing immutable objects and Records, pure functions, functional interfaces, lambda expressions, Stream API pipelines, Optional for null safety, function composition, higher-order functions, pattern matching for instanceof and switch, sealed classes/interfaces for controlled hierarchies, Stream Gatherers for custom operations, currying/partial application, effect boundary separation, and concurrent-safe functional patterns. This should trigger for requests such as Improve the code with Functional Programming; Apply Functional Programming; Refactor the code with Functional Programming; Refactor Java code to use streams or Optionals safely; Improve immutability and pure functions in Java. Part of Plinth Toolkit

Use when you need to set up JMeter performance testing for a Java project — including creating the run-jmeter.sh script from the exact template, configuring load tests with loops, threads, and ramp-up, or running performance tests from the project root with custom or default settings. This should trigger for requests such as Improve the code with JMeter performance testing; Apply JMeter performance testing; Refactor the code with JMeter performance testing; Add JMeter support; Create a JMeter test plan for a Java service. Part of Plinth Toolkit

Use when you need to design, review, or improve validation in Micronaut applications — including Bean Validation on @Controller methods, @Body @Valid, query/path parameter validation, @ConfigurationProperties validation, custom constraints, nested DTO validation, and ExceptionHandler mapping for constraint violations. This should trigger for requests such as Add validation support in Micronaut; Review Micronaut validation rules; Improve request validation in Micronaut REST APIs; Add custom validation constraints in Micronaut; Validate Micronaut configuration properties. Part of Plinth Toolkit

Use when creating or updating OpenSpec change artifacts from an issue, implementation plan, approved design, ADRs, existing OpenSpec artifacts, or a valid combination. The workflow assesses whether the scope is one change or multiple changes, records sources and derivation direction, and prevents silent synchronization. This should trigger for requests such as Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes. Part of Plinth Toolkit

Use when you need GitHub CLI (`gh`) installation/authentication guidance and a sanitized GitHub issue inventory workflow. The agent does not ingest GitHub issue or milestone output directly; it asks the user for sanitized issue summaries before analysis or @014-agile-user-story handoff. This should trigger for requests such as GitHub issue summary workflow; GitHub CLI setup for issues; Prepare sanitized GitHub issue inventory; Analyze GitHub issues with gh CLI; Summarize milestones and issue discussions safely. Part of Plinth Toolkit

Guides the creation of agile user stories and Gherkin feature files. Use when the user wants to create a user story, write acceptance criteria, define Gherkin scenarios, or author BDD feature files. This should trigger for requests such as Create a user story; Write a user story; I need to write a user story; Create Gherkin scenarios for a user story; Split feature requirements into user stories. Part of Plinth Toolkit