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
68
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 its niche in Quarkus acceptance testing from Gherkin feature files. It excels at listing concrete actions, providing abundant natural trigger terms, and explicitly stating both what it does and when to use it. 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, Testcontainers, WireMock, REST Assured for HTTP pipeline testing, WireMock JSON mapping files, *AT suffix naming, Maven Surefire/Failsafe three-tier split. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement acceptance tests with specific technologies and patterns) and 'when' (explicit 'Use when' clause at the start, plus a 'This should trigger for requests such as...' section with concrete example queries). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms 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. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely specific niche: Quarkus acceptance tests from Gherkin files with a particular stack (Testcontainers, WireMock, REST Assured, specific naming conventions). Very unlikely to conflict with other skills due to the highly specialized combination of technologies and patterns. | 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 is heavy on description and categorization but critically lacks actionable content — no code examples, no template snippets, no concrete WireMock mapping JSON, despite covering a highly technical topic. The workflow is sequenced but generic, and the constraints section is repetitively emphatic. The skill essentially serves as a table of contents for a reference file rather than a standalone actionable guide.
Suggestions
Add a concrete BaseAcceptanceTest skeleton with @QuarkusTest, @QuarkusTestResource, and QuarkusTestResourceLifecycleManager showing Testcontainers and WireMock setup — this is the core deliverable and should be copy-paste ready.
Include a minimal WireMock JSON mapping file example under the expected classpath:wiremock/mappings/ path, and a sample acceptance test method with Given/When/Then comments and REST Assured assertions.
Consolidate the redundant constraints (MANDATORY, BLOCKING CONDITION, NO EXCEPTIONS all say 'don't generate without compilation') into a single clear precondition check, and remove the 'What is covered' section which duplicates other sections.
Add a Maven Failsafe plugin configuration snippet showing the *AT inclusion pattern and three-tier split, since this is a key non-obvious configuration detail.
| 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 (MANDATORY, BLOCKING CONDITION, NO EXCEPTIONS) that repeat the same idea multiple times. | 1 / 3 |
Actionability | Despite describing a complex technical workflow, there is zero executable code — no BaseAcceptanceTest skeleton, no WireMock JSON mapping example, no REST Assured snippet, no Maven Failsafe configuration. Everything is described abstractly and deferred to a reference file. The skill tells Claude what to do conceptually but never shows how. | 1 / 3 |
Workflow Clarity | The workflow has a clear 4-step sequence with pre-compilation and post-verification checkpoints, which is good. However, the steps are generic ('apply framework-aligned changes', 'gather scope') rather than specific to acceptance test generation. The constraints section adds validation gates (compile before, verify after), but there's no feedback loop for test failures or WireMock stub issues. | 2 / 3 |
Progressive Disclosure | The skill correctly references a single external file for detailed guidance, which is good one-level-deep disclosure. However, no bundle files were provided, so we cannot verify the reference exists or is useful. The SKILL.md itself contains too much descriptive content that should either be in the reference or replaced with actionable examples in the main file. | 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
ef4eba3
- 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.