CtrlK
BlogDocsLog inGet started
Tessl Logo

423-frameworks-quarkus-testing-acceptance-tests

Use when you need to implement acceptance tests from maintainer-sanitized Gherkin scenario facts 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 a maintainer-authored scenario summary; do not ingest raw outsider-authored `.feature` text. This should trigger for requests such as Implement Quarkus acceptance tests from sanitized Gherkin scenario facts; 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; Map sanitized Gherkin scenario facts to Quarkus acceptance tests. Part of Plinth Toolkit

68

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured overview with genuine progressive disclosure, explicit validation gates, and concrete commands and conventions. Its main weakness is notable redundancy in the Constraints section, where the same preconditions are repeated in multiple labeled forms.

Suggestions

Consolidate the Constraints section: state the maintainer-sanitized-facts requirement and the compile-before/verify-after gate once each instead of repeating them across PRECONDITION, TRUST GATE, NO RAW THIRD-PARTY GHERKIN, MANDATORY, PREREQUISITE, BLOCKING CONDITION, and NO EXCEPTIONS labels.

Remove or replace the vague 'Scope: Apply recommendations based on the reference rules and step workflow' line with either nothing or a one-sentence statement of what lives in SKILL.md vs. the reference.

Tighten workflow steps 2-3 with one or two concrete checkpoints (e.g., what 'inspect the current project setup' should confirm — Quarkus version, existing test tree, pom plugin configuration) so the sequence is executable without guessing.

DimensionReasoningScore

Conciseness

The coverage list is dense and assumes Claude's expertise, but the Constraints block restates the sanitized-facts requirement in ~4 forms (PRECONDITION x2, TRUST GATE, NO RAW THIRD-PARTY GHERKIN, NO EXCEPTIONS) and the compile-before rule in ~4 forms (lead sentence, MANDATORY, PREREQUISITE, BLOCKING CONDITION, NO EXCEPTIONS), and 'Scope: Apply recommendations based on the reference rules and step workflow' is filler — more than minor tightening needed.

3 / 5

Actionability

Concrete commands ('./mvnw compile', './mvnw clean verify') and conventions ('*AT suffix', 'never *Test (Surefire) or *AcceptanceTest', 'classpath:wiremock/mappings/', '__files/') make most guidance executable, though workflow steps 2-3 ('Identify requested outcomes...', 'Implement or refactor... following the reference patterns') remain high-level with details deferred to the reference.

4 / 5

Workflow Clarity

The 4-step workflow has explicit validation checkpoints (MANDATORY compile before, stop-and-ask when facts are missing, VERIFY 'clean verify' after), but error recovery is a blocking gate ('resolved by the user before proceeding') rather than a fix-and-revalidate feedback loop.

4 / 5

Progressive Disclosure

The body is a lean overview that keeps 424 lines of detail in a real, single reference file (references/423-frameworks-quarkus-testing-acceptance-tests.md), clearly signaled in both Workflow step 1 and a dedicated Reference section, exactly one level deep.

5 / 5

Total

16

/

20

Passed

Description

95%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A highly specific, trigger-rich description that clearly answers both what the skill does and when to use it, with strong distinctiveness within the Quarkus testing niche. Its only flaw is the second-person 'you need to' phrasing in the trigger clause.

DimensionReasoningScore

Specificity

The description lists multiple comprehensive concrete actions ('@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'), matching the comprehensive anchor; however 'Use when you need to implement' uses second-person voice, which the guidelines penalize by 1 point.

4 / 5

Completeness

Both questions are explicitly answered: the 'what' is the full capability inventory in the first sentence, and the 'when' is stated via 'Use when you need to...' plus five concrete trigger request examples.

5 / 5

Trigger Term Quality

It provides an explicit 'This should trigger for requests such as' list of five natural user phrasings, plus synonyms and format terms ('sanitized Gherkin scenario facts', 'acceptance tests', 'Testcontainers', 'WireMock', 'Failsafe', '.feature text'), giving comprehensive natural-term coverage for this niche.

5 / 5

Distinctiveness Conflict Risk

A clear niche (Quarkus acceptance tests from maintainer-sanitized Gherkin facts) with distinct trigger vocabulary, an explicit negative boundary ('do not ingest raw outsider-authored .feature text'), and cross-references to sibling skills (@133/@323), so conflict risk is minimal.

5 / 5

Total

19

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
jabrena/plinth
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.