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. Part of the skills-for-java project
77
71%
Does it follow best practices?
Impact
Pending
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 test implementation from Gherkin feature files. It excels at listing concrete technologies and patterns, includes an explicit 'Use when' trigger, and is distinctive enough to avoid conflicts. The only minor weakness is that it reads as a dense list of technologies which could be slightly better organized, but the content itself is comprehensive and precise.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and technologies: implementing acceptance tests from Gherkin .feature files, @QuarkusTest, BaseAcceptanceTest with QuarkusTestResourceLifecycleManager, Testcontainers, WireMock, REST Assured for HTTP pipeline testing, WireMock JSON mapping files, *AT suffix naming, and Maven Surefire/Failsafe three-tier split. | 3 / 3 |
Completeness | Starts with an explicit 'Use when' clause that clearly answers both what (implement acceptance tests from Gherkin .feature files for Quarkus applications with specific tooling) and when (when you need to implement acceptance tests from a .feature file). Also notes the prerequisite of having the .feature file in context. | 3 / 3 |
Trigger Term Quality | Includes many natural keywords a user working in this domain would use: 'acceptance tests', 'Gherkin', '.feature file', 'Quarkus', '@QuarkusTest', 'Testcontainers', 'WireMock', 'REST Assured', 'Maven Surefire/Failsafe'. These are highly specific and natural terms for the target audience. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely specific niche: Quarkus acceptance tests from Gherkin feature files with a very particular tech stack (Testcontainers, WireMock, REST Assured, specific naming conventions, Maven split). This is highly unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill functions primarily as a pointer to a reference file, providing a reasonable overview and clear navigation but almost no actionable content in the body itself. The constraints section establishes important guardrails but is repetitive, and the complete absence of code examples or concrete step-by-step instructions means Claude would be entirely dependent on the reference file to do anything useful. The skill would benefit significantly from at least a minimal executable quick-start example inline.
Suggestions
Add a concrete, executable quick-start example showing a minimal BaseAcceptanceTest class and one test method with REST Assured + WireMock, so the skill body is actionable without requiring the reference file.
Consolidate the redundant constraint entries (e.g., merge the two PRECONDITION lines and the multiple 'do not generate' rules) to improve conciseness.
Replace the 'What is covered' bullet list with a numbered step-by-step workflow (1. Verify preconditions → 2. Compile → 3. Parse .feature → 4. Generate BaseAcceptanceTest → 5. Generate test class → 6. Create WireMock mappings → 7. Verify) to improve workflow clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'What is covered in this Skill?' section is essentially a verbose table of contents that restates what the reference file covers without adding executable value. The constraints section has redundant emphasis (PRECONDITION listed twice, multiple ways of saying 'don't generate without prerequisites'). However, it's not egregiously padded with explanations of basic concepts. | 2 / 3 |
Actionability | There is no concrete code, no executable examples, no copy-paste ready snippets. The skill describes what should be done at a high level (BaseAcceptanceTest, REST Assured, WireMock mappings) but provides zero actual code or commands beyond generic 'mvnw compile' and 'mvn clean verify'. Everything actionable is deferred to the reference file. | 1 / 3 |
Workflow Clarity | There is an implicit workflow: check preconditions → compile → generate tests → verify. The constraints section establishes validation checkpoints (compile before, verify after, block on errors). However, the steps are not clearly sequenced in a numbered workflow, and the feedback loop for compilation failure is mentioned but not structured as an explicit retry loop. | 2 / 3 |
Progressive Disclosure | The skill clearly serves as an overview that points to a single reference file for detailed guidance, examples, and constraints. The reference is one level deep and clearly signaled with a relative link. The 'When to use this skill' section aids discovery. | 3 / 3 |
Total | 8 / 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.
1847adc
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.