414-frameworks-quarkus-kafka

Use when you need Kafka messaging in Quarkus with SmallRye Reactive Messaging — including channel/topic design, build-time Jackson serialization, typed @Channel/@Incoming, ack/failure strategies, retries/DLQ, idempotency, Dev Services, and Testcontainers integration tests. This should trigger for requests such as Add Kafka in Quarkus; Review Reactive Messaging consumers; Improve failure handling for Quarkus Kafka; Configure Quarkus Reactive Messaging Kafka channels; Add Quarkus Kafka failure strategy or DLQ handling. Part of Plinth Toolkit

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

78%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 skill: lean constraints, a sequenced workflow with compile/verify checkpoints, and clean progressive disclosure to a substantial reference file. The main weaknesses are redundancy with the frontmatter description (the 'When to use' section and repeated read-the-reference instructions) and abstract, non-recoverable middle workflow steps.

Suggestions

Remove or shrink the 'When to use this skill' section — it duplicates the frontmatter description's trigger list, which is already always loaded, and consolidate the three separate 'read the reference' mentions into Workflow step 1.

Make Workflow steps 2-3 concrete: name the specific artifacts to inspect (application.properties channel config, @Incoming/@Channel classes) and the exact commands or checks to run, instead of 'Identify delivery semantics and resilience goals'.

Add an explicit error-recovery loop after verification: e.g. 'If verify fails, fix the failing changes and re-run mvn clean verify before reporting', rather than only the compile-time 'stop immediately' condition.

Dimension	Reasoning	Score
Conciseness	The body is lean and imperative with no concept explanations Claude already knows, but tokens do not all earn their place: the 'When to use this skill' section restates the frontmatter description's trigger list verbatim, and the instruction to read the reference file appears three times (Constraints 'BEFORE APPLYING', Workflow step 1, and the Reference section). Anchor 4 ('minor instances of over-explanation that could be trimmed') fits better than anchor 5.	4 / 5
Actionability	Concrete, executable commands are present ('./mvnw compile', 'mvn clean verify') plus an exact reference path, and code examples are appropriately deferred to the real 459-line reference file. However Workflow steps 2 and 3 are abstract ('Identify delivery semantics and resilience goals', 'Implement/refactor channels, serializers, and failure strategies') without naming specific files, configs, or checks, which is a minor gap versus anchor 5.	4 / 5
Workflow Clarity	A clear four-step sequence exists with real validation checkpoints (mandatory compile before changes, 'If compilation fails, stop immediately', verify after). It falls short of anchor 5 because there is no error-recovery feedback loop after verification fails — no 'fix and re-verify' guidance — only a stop condition, leaving a minor validation gap per anchor 4.	4 / 5
Progressive Disclosure	The SKILL.md body is a concise overview that points to a single, well-signaled, one-level-deep reference (references/414-frameworks-quarkus-kafka.md, verified to exist and contain the detailed examples/constraints), with all detail appropriately split out of the overview. This matches the anchor-5 pattern exactly and is not anchor 4, since navigation is unambiguous and nothing that belongs in the reference is inlined.	5 / 5
	Total	17 / 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 strong description: concrete capability inventory, explicit and natural trigger phrases, and a well-delineated Quarkus-Kafka niche. The only defect is second-person voice ('Use when you need'), which costs it specificity points under the rubric's third-person rule; the closing 'Part of Plinth Toolkit' adds no trigger value.

Dimension	Reasoning	Score
Specificity	The description comprehensively lists concrete capabilities ('channel/topic design, build-time Jackson serialization, typed @Channel/@Incoming, ack/failure strategies, retries/DLQ, idempotency, Dev Services, and Testcontainers integration tests'), which is anchor-5 coverage, but it uses second person voice ('Use when you need Kafka messaging'), which the rubric penalizes by reducing specificity by 1.	4 / 5
Completeness	It clearly answers 'what' (the enumerated Kafka messaging capabilities with SmallRye Reactive Messaging) and 'when' ('Use when you need Kafka messaging in Quarkus... This should trigger for requests such as...'), with concrete trigger phrases matching the anchor-5 example pattern. It is not anchor 4 because the 'when' is explicit and specific rather than merely present.	5 / 5
Trigger Term Quality	It explicitly enumerates natural trigger phrasings users would actually say: 'Add Kafka in Quarkus', 'Review Reactive Messaging consumers', 'Improve failure handling for Quarkus Kafka', 'Configure Quarkus Reactive Messaging Kafka channels', 'Add Quarkus Kafka failure strategy or DLQ handling', plus synonyms like DLQ and idempotency. Coverage is comprehensive; it is not below anchor 5 because no commonly used natural variation of these requests is missing.	5 / 5
Distinctiveness Conflict Risk	A clear niche is staked out — Kafka messaging specifically within Quarkus via SmallRye Reactive Messaging — and every trigger phrase names Quarkus, minimizing conflict with generic Kafka or other-framework messaging skills. The trailing 'Part of Plinth Toolkit' is mild noise but does not create trigger overlap.	5 / 5
	Total	19 / 20 Passed

Validation

100%

Warnings & errors only

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
Path: skills/414-frameworks-quarkus-kafka/SKILL.md
Commit: dca88dc

Reviewed: 3 hours ago

Table of Contents

Discovery Implementation Validation

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.