132-java-testing-integration-testing

Use when you need to set up, review, or improve Java integration tests — including generating a BaseIntegrationTest.java with WireMock for HTTP stubs, detecting HTTP client infrastructure from import signals, injecting service coordinates dynamically via System.setProperty(), creating WireMock JSON mapping files with bodyFileName, isolating stubs per test method, verifying HTTP interactions, or eliminating anti-patterns such as Mockito-mocked HTTP clients or globally registered WireMock stubs. This should trigger for requests such as Review Java code for integration tests; Apply best practices for integration tests in Java code; Write Java integration tests with real infrastructure boundaries; Improve Testcontainers integration tests for Java code; Review integration test setup and teardown in Java projects. Part of Plinth Toolkit

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

70%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured overview with a clear, validated workflow and clean one-level-deep progressive disclosure to a real reference file. Weaker on conciseness (duplicated compile/verify rules and trigger phrases) and actionability (executable code deferred entirely to the reference).

Suggestions

Remove the compile/verify duplication by stating the rule once in "Constraints" and having the Workflow reference it rather than restate it.

Drop or compress the "When to use this skill" section since the same triggers already appear in the frontmatter description.

Include one small inline code snippet (e.g. the BaseIntegrationTest skeleton or a WireMock stub) so the body is actionable without always opening the reference.

Dimension	Reasoning	Score
Conciseness	The body is lean and avoids explaining concepts Claude already knows, but content is duplicated: the compile-before / verify-after rules appear in both "Constraints" and "Workflow", and "When to use this skill" restates trigger phrases already in the frontmatter description.	2 / 3
Actionability	It gives concrete executable commands ("./mvnw compile", "mvn clean verify") and names specific constructs (BaseIntegrationTest, WireMockExtension, dynamicPort(), System.setProperty, bodyFileName), but the full executable code examples live in the reference rather than inline in the body.	2 / 3
Workflow Clarity	A clear 4-step sequence with explicit validation checkpoints and a feedback loop: "Run ./mvnw compile... and stop immediately if compilation fails" and "Run ./mvnw clean verify after applying improvements".	3 / 3
Progressive Disclosure	The body is a concise overview with well-organized sections that points to a single one-level-deep reference (references/132-java-testing-integration-testing.md, verified to exist) signaled in both the workflow and a dedicated Reference section.	3 / 3
	Total	10 / 12 Passed

Description

90%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, specific description with strong trigger coverage, explicit what/when guidance, and a clear niche. The main issue is second-person voice ("Use when you need to"), which the rubric penalizes, and slight verbosity from enumerating many capabilities in a single sentence.

Suggestions

Rewrite the trigger clause in third person to match the rubric's good examples, e.g. "Use when setting up, reviewing, or improving Java integration tests" instead of "Use when you need to...".

The trigger list mentions Testcontainers, but the skill is WireMock-based; either drop that trigger or clarify the relationship to avoid over-claiming.

Tighten the long capability enumeration so the description stays scannable rather than padded.

Dimension	Reasoning	Score
Specificity	Lists many concrete actions ("generating a BaseIntegrationTest.java with WireMock", "detecting HTTP client infrastructure from import signals", "injecting service coordinates dynamically via System.setProperty()"), which would rate 3, but the opening "Use when you need to" is second-person voice, which the rubric penalizes by reducing specificity by 1.	2 / 3
Completeness	It explicitly answers both what (the enumerated WireMock/BaseIntegrationTest capabilities) and when ("Use when you need to..." plus "This should trigger for requests such as...").	3 / 3
Trigger Term Quality	Natural user phrasings are well covered: "Review Java code for integration tests", "Apply best practices for integration tests in Java code", "Write Java integration tests", "Improve Testcontainers integration tests", and "Review integration test setup and teardown".	3 / 3
Distinctiveness Conflict Risk	It carves a clear niche (Java integration tests with WireMock, named anti-patterns like Mockito-mocked HTTP clients) with distinct triggers unlikely to fire for unrelated skills.	3 / 3
	Total	11 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: jabrena/plinth
Commit: aaee915

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.