423-frameworks-quarkus-testing-acceptance-tests
Use when you need to implement acceptance tests from a Gherkin .feature file for Quarkus applications — including @acceptance scenarios, @QuarkusTest, BaseAcceptanceTest with QuarkusTestResourceLifecycleManager for Testcontainers and WireMock, REST Assured for full HTTP pipeline testing, WireMock JSON mapping files (classpath:wiremock/mappings/), *AT suffix naming, and Maven Surefire/Failsafe three-tier split. Requires the .feature file in context. This should trigger for requests such as Implement Quarkus acceptance tests from a Gherkin feature file; Set up BaseAcceptanceTest with Testcontainers and WireMock for Quarkus; Create WireMock JSON mapping files for external HTTP stubs in Quarkus acceptance tests; Configure Maven *AT naming convention and Failsafe plugin for Quarkus acceptance tests. Part of cursor-rules-java project
54
60%
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/423-frameworks-quarkus-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, highly specific skill description that clearly defines a narrow niche (Quarkus acceptance test implementation from Gherkin files) with comprehensive tooling details and explicit trigger guidance. It includes concrete example requests that would help Claude match user queries accurately. The only minor weakness is that it's quite dense and could benefit from slightly better formatting for readability, but the content itself is excellent.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: implementing acceptance tests from Gherkin .feature files, BaseAcceptanceTest with QuarkusTestResourceLifecycleManager for Testcontainers and WireMock, REST Assured for full HTTP pipeline testing, WireMock JSON mapping files, *AT suffix naming, and Maven Surefire/Failsafe three-tier split. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement acceptance tests from Gherkin files with specific tooling stack) and 'when' with explicit trigger guidance via 'Use when...' clause and 'This should trigger for requests such as...' with four concrete example requests. | 3 / 3 |
Trigger Term Quality | Includes many natural keywords users would say: 'Gherkin', '.feature file', 'Quarkus', 'acceptance tests', 'Testcontainers', 'WireMock', 'REST Assured', 'BaseAcceptanceTest', 'Maven Failsafe', '*AT naming convention'. These are highly specific terms a developer would naturally use when requesting this kind of work. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely specific niche combining Quarkus + Gherkin acceptance tests + Testcontainers + WireMock + specific naming conventions. This is unlikely to conflict with other skills due to the highly specialized technology stack and pattern described. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
20%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill describes a sophisticated testing workflow but fails to provide any concrete, executable guidance — no code examples, no template snippets, no sample WireMock mappings. It is verbose with redundant sections (description, 'What is covered', 'When to use') and over-emphasized constraints that repeat the same compilation-check idea five different ways. The entire actionable content is deferred to a reference file that wasn't provided for evaluation.
Suggestions
Add a concrete BaseAcceptanceTest code skeleton with @QuarkusTest, @QuarkusTestResource, and QuarkusTestResourceLifecycleManager showing Testcontainers and WireMock setup — this is the core deliverable and should be copy-paste ready.
Include at least one complete example acceptance test class showing the Given/When/Then pattern with REST Assured and WireMock verify, derived from a sample Gherkin scenario.
Add a sample WireMock JSON mapping file and the corresponding Maven Failsafe plugin configuration snippet for the *AT naming convention.
Remove the 'What is covered' section entirely — it duplicates the description and 'When to use' section without adding actionable value. Consolidate the constraints into 2-3 concise bullet points instead of 8 redundant ones.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is verbose and repetitive. The 'What is covered' section largely duplicates the 'When to use this skill' section and the description. Bullet points explain concepts Claude already knows (e.g., what WireMock does, what Testcontainers are). The constraints section is padded with redundant emphasis labels (PRECONDITION, MANDATORY, BLOCKING CONDITION, NO EXCEPTIONS) that repeat the same idea multiple times. | 1 / 3 |
Actionability | Despite describing a complex multi-step technical process, the skill contains zero executable code examples — no BaseAcceptanceTest skeleton, no WireMock JSON mapping example, no REST Assured test snippet, no Maven Failsafe configuration. Everything is described abstractly and deferred to a reference file. The workflow steps are generic ('apply framework-aligned changes') rather than concrete. | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with compilation verification before and after changes, which is good. However, the steps are abstract and lack specific validation checkpoints within the test generation process itself. The constraints section adds pre/post compilation checks, but the actual workflow of parsing Gherkin, creating test classes, and setting up WireMock mappings lacks detailed sequencing. | 2 / 3 |
Progressive Disclosure | The skill references a detailed reference file (references/423-frameworks-quarkus-testing-acceptance-tests.md) which is appropriate progressive disclosure. However, no bundle files were provided to verify the reference exists, and the SKILL.md itself contains too much descriptive content that should either be in the reference or replaced with actionable inline examples. The 'What is covered' section is essentially a table of contents for content that lives elsewhere. | 2 / 3 |
Total | 6 / 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
3fa5789
- 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.