133-java-testing-acceptance-tests
Use when you need to implement acceptance tests from a Gherkin .feature file for framework-agnostic Java (no Spring Boot, Quarkus, Micronaut) — finding @acceptance scenarios, happy path with RestAssured, Testcontainers for DB/Kafka, WireMock for external REST. Requires .feature file in context. This should trigger for requests such as Review Java code for acceptance tests; Apply best practices for acceptance tests in Java code. Part of cursor-rules-java project
85
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong, well-crafted description that clearly defines a specific niche (framework-agnostic Java acceptance testing from Gherkin files), lists concrete tools and actions, and provides explicit trigger guidance. The description effectively distinguishes itself from related skills by explicitly excluding popular frameworks and naming specific testing libraries. Minor improvement could be made by slightly tightening the prose, but overall it serves its purpose very well.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: finding @acceptance scenarios, happy path with RestAssured, Testcontainers for DB/Kafka, WireMock for external REST. Also specifies the technology stack clearly (framework-agnostic Java, no Spring Boot/Quarkus/Micronaut). | 3 / 3 |
Completeness | Clearly answers both what (implement acceptance tests from Gherkin .feature files using RestAssured, Testcontainers, WireMock) and when ('Use when you need to implement acceptance tests from a Gherkin .feature file', 'should trigger for requests such as Review Java code for acceptance tests'). Has explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'acceptance tests', 'Gherkin', '.feature file', 'RestAssured', 'Testcontainers', 'WireMock', 'Java code', 'best practices for acceptance tests'. Good coverage of both domain terms and tool names. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche: framework-agnostic Java acceptance tests from Gherkin files with specific tooling (RestAssured, Testcontainers, WireMock). Explicitly excludes Spring Boot/Quarkus/Micronaut, reducing overlap with framework-specific skills. Unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has a well-structured workflow with clear validation checkpoints and safety constraints, which is its strongest aspect. However, it suffers from being too abstract in the SKILL.md itself — nearly all concrete implementation guidance is deferred to a reference file, leaving the main skill without executable code examples. There is also some redundancy in how preconditions and scope are stated across multiple sections.
Suggestions
Add at least one concrete, executable code example in the SKILL.md body — e.g., a minimal BaseAcceptanceTest skeleton with Testcontainers setup and a sample RestAssured test method — so the skill is actionable without requiring the reference file.
Remove redundant precondition statements that appear in both the intro paragraph, the Constraints section, and the Workflow step 1; state them once clearly.
Trim the 'What is covered' bullet list to only items that aren't obvious from the skill title and workflow — e.g., remove bullets like 'RestAssured for REST API testing (given/when/then, status codes, JSON body assertions)' which explain what Claude already knows.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered' bullet list is somewhat redundant with the workflow and constraints sections, and some items (like explaining what RestAssured/Testcontainers/WireMock do) are things Claude already knows. The repeated precondition statements across multiple sections add unnecessary verbosity. However, it's not egregiously padded. | 2 / 3 |
Actionability | The skill provides concrete commands (mvnw compile, mvn clean verify) and specific tool names, but lacks any executable code examples for the actual test implementation — no sample BaseAcceptanceTest class, no RestAssured snippet, no WireMock stub example. It delegates all concrete guidance to the reference file, making the SKILL.md itself more of a pointer than an actionable guide. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced with four explicit steps, includes validation checkpoints (compile before changes, verify after), has a clear stop condition if compilation fails, and follows a logical progression from precondition validation through implementation to verification. | 3 / 3 |
Progressive Disclosure | The skill correctly references a single external file (references/133-java-testing-acceptance-tests.md) for detailed examples, which is good one-level-deep disclosure. However, since no bundle files were provided, we cannot verify the reference exists, and the SKILL.md itself is too thin on actionable content — it over-delegates to the reference, leaving the main file without enough standalone value. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- jabrena/cursor-rules-java
- Commit
762cb86
- Reviewed
Table of Contents
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.