Use when you need to implement acceptance tests from a Gherkin .feature file for Spring Boot applications — including finding scenarios tagged @acceptance, implementing happy path tests with TestRestTemplate, @SpringBootTest, Testcontainers with @ServiceConnection for DB/Kafka, and WireMock for external REST stubs. Requires .feature file in context. This should trigger for requests such as Review Java code for Spring Boot acceptance tests; Apply best practices for Spring Boot acceptance tests in Java code. Part of cursor-rules-java project
59
67%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/323-frameworks-spring-boot-testing-acceptance-tests/SKILL.mdQuality
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 narrow niche (Spring Boot acceptance test implementation from Gherkin feature files) with specific technologies and explicit trigger guidance. It covers both 'what' and 'when' thoroughly, includes natural trigger terms, and is distinctive enough to avoid conflicts with related skills. The only minor weakness is slight verbosity, but the detail serves the purpose of disambiguation.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: implementing acceptance tests from Gherkin .feature files, finding scenarios tagged @acceptance, implementing happy path tests with TestRestTemplate, @SpringBootTest, Testcontainers with @ServiceConnection for DB/Kafka, and WireMock for external REST stubs. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement acceptance tests from Gherkin files with specific technologies) and 'when' (explicit 'Use when' clause at the start, plus 'This should trigger for requests such as...' with concrete examples). Also states a prerequisite: 'Requires .feature file in context.' | 3 / 3 |
Trigger Term Quality | Includes many natural keywords users would say: 'acceptance tests', 'Gherkin', '.feature file', 'Spring Boot', 'TestRestTemplate', 'Testcontainers', 'WireMock', 'Java code', 'best practices'. Good coverage of both high-level and specific technical terms a developer would use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche: Spring Boot acceptance tests specifically from Gherkin .feature files, with a very specific tech stack (TestRestTemplate, Testcontainers, WireMock). Unlikely to conflict with general Java testing or other Spring Boot skills due to the narrow focus on acceptance test implementation from feature files. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is structured as a high-level overview that delegates nearly all actionable content to a reference file, but the reference file is not available in the bundle. The main file is verbose in describing scope and coverage but lacks any concrete code examples, making it difficult for Claude to act on without the reference. The workflow provides a reasonable sequence but with vague steps and incomplete feedback loops.
Suggestions
Add at least one complete, executable example test class showing the key patterns (e.g., @SpringBootTest + TestRestTemplate + Testcontainers + WireMock) so the skill is actionable even without the reference file.
Trim the 'What is covered' bullet list significantly — most items describe concepts Claude already knows. Replace with a brief summary and let the code example demonstrate the patterns.
Add explicit error-recovery guidance in the workflow: what to do if tests fail after step 4, how to diagnose common issues (e.g., container startup failures, WireMock stub mismatches).
Ensure the referenced file 'references/323-frameworks-spring-boot-testing-acceptance-tests.md' is included in the bundle so the progressive disclosure actually works.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered' section is essentially a verbose bullet-point list that restates things Claude already knows (e.g., what TestRestTemplate does, what Testcontainers is for). The constraints and workflow sections are reasonably tight but the overall content could be significantly tightened. | 2 / 3 |
Actionability | There are no concrete code examples, no executable snippets, no sample test class, and no specific commands beyond generic 'mvn compile'. The skill describes what to do abstractly but delegates all actual implementation details to a reference file that wasn't provided. Claude would not know exactly what code to write from this content alone. | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with compilation precondition and verification steps, which is good. However, the steps are vague ('Apply framework-aligned changes', 'Gather scope') and lack specific validation checkpoints between steps — e.g., no explicit 'if tests fail, do X' feedback loop after step 4. | 2 / 3 |
Progressive Disclosure | The skill references a single detailed reference file with a clear path, which is good structure. However, since no bundle files were provided, we can't verify the reference exists. The main file contains too much inline description (the 'What is covered' list) that could be in the reference, while lacking the concrete examples that should be in the main file. | 2 / 3 |
Total | 7 / 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.
26e9744
Table of Contents
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.