CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/mqtt-tests

Test MQTT v5.0 with Mosquitto broker in CI + paho-mqtt clients - QoS 0 / 1 / 2 delivery semantics, retained messages, Last Will and Testament (LWT), shared subscriptions ($share/group/topic), $SYS topic introspection. Critical for IoT, embedded, and M2M systems where wire-level guarantees matter. Also carries STOMP-over-WebSocket + AMQP 0-9-1 broker testing (Spring / RabbitMQ frame, ack-mode, and exchange/binding tests via Testcontainers) in references/stomp-amqp.md. Use when a product speaks MQTT, STOMP, or AMQP on the wire and QoS 1 / 2 redelivery, retained-message state, LWT, ack-mode, or broker-topology behavior needs a broker-backed test - including smoke-testing a new broker auth / ACL / persistence config.

75

Quality

94%

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

Overview
Quality
Evals
Security
Files

Quality

Content

86%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 strong, execution-first skill body: concrete CI config, complete modern-paho test code, a numbered workflow with in-code validation, and a clean split of advanced LWT/shared-subscription/$SYS and STOMP/AMQP material into verified one-level-deep reference files. The only real cost is redundancy — the worked example and repeated clean_start caveats duplicate Step 3 — and the absence of an explicit test-run command.

Suggestions

Collapse the 'Worked example' section into a one-line pointer to Step 3 (or replace it with a genuinely different scenario), since it currently restates the QoS 1 redelivery test already shown in full; likewise state the clean_start=False caveat once (Step 3) and let the anti-patterns table carry the failure-mode framing.

Add an explicit run step to the workflow (e.g., `pytest tests/test_mqtt_qos.py -x` against the CI service) so the execute-and-observe-failures loop is stated, not implied by test_* naming.

DimensionReasoningScore

Conciseness

The body is dominated by tight, executable test code with no padding explaining concepts Claude already knows, but there is trimmable redundancy: the "Worked example" section re-walks Step 3's QoS 1 redelivery test in prose ("Connect a subscriber with clean_start=False... Reconnect the subscriber... Assert b'22.5' in received") after the full test function already appears, and the clean_start caveat is stated three times ("`clean_start=False` is required for the broker to retain offline session state", the worked example, and the anti-patterns table). This is more than the every-token-earns-its-place of a 5, but well short of the unnecessary-explanation level of a 3.

4 / 5

Actionability

Everything needed to execute is copy-paste ready: the GitHub Actions service YAML, the mosquitto.conf contents, `pip install paho-mqtt`, and two complete pytest-style test functions using the current paho API (`callback_api_version=mqtt.CallbackAPIVersion.VERSION2`, `.wait_for_publish()`), covering the two most common cases (QoS 1 redelivery, retained delivery to a late subscriber). The only gap is negligible — no `import time` in the Step 3/4 snippets — which does not rise to the 'minor gaps' of a 4.

5 / 5

Workflow Clarity

A clear numbered 6-step "How to use" sequence cross-references each detailed section, every example test carries an explicit assertion as an in-code validation checkpoint, and the anti-patterns table maps failure to cause to fix (e.g., "Use clean_start=True then expect persistence → Broker discards session; QoS 1 buffer lost → clean_start=False"). It falls short of a 5 because there is no explicit command to run the suite (pytest is only implied by test_* names) and no explicit error-recovery loop beyond the anti-patterns table; it is clearly above a 3 since sequence and checkpoints are explicit and no destructive/batch cap applies to authoring tests.

4 / 5

Progressive Disclosure

Core content (broker setup, client wiring, QoS matrix, retained messages) lives inline, while advanced material is split exactly one level deep into real bundle files, each clearly signaled at point of use ("See [references/lwt-shared-subs-sys.md] for Last Will and Testament on abnormal disconnect, shared-subscription round-robin ($share/<group>/<topic>), and $SYS broker-diagnostics tests") and again in a References section. Both referenced files exist in references/, and the frontmatter description also flags references/stomp-amqp.md — a well-signaled, easy-to-navigate structure.

5 / 5

Total

18

/

20

Passed

Description

100%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.

The description is exemplary: it names concrete capabilities with specific tools (Mosquitto, paho-mqtt, Testcontainers, RabbitMQ), covers natural trigger terms comprehensively including synonyms, and explicitly states both what the skill does and when to use it with a detailed 'Use when' clause. Third-person voice is used throughout with no fluff or over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete, tool-named actions: "Test MQTT v5.0 with Mosquitto broker in CI + paho-mqtt clients - QoS 0 / 1 / 2 delivery semantics, retained messages, Last Will and Testament (LWT), shared subscriptions ($share/group/topic), $SYS topic introspection", plus "STOMP-over-WebSocket + AMQP 0-9-1 broker testing (Spring / RabbitMQ frame, ack-mode, and exchange/binding tests via Testcontainers)" and "smoke-testing a new broker auth / ACL / persistence config". Coverage is comprehensive with no notable gaps, matching the score-5 anchor rather than the 'minor gaps' of 4.

5 / 5

Completeness

Explicitly answers both questions: the "what" is the full MQTT v5.0 test surface plus STOMP/AMQP in references/stomp-amqp.md, and the "when" is a concrete trigger clause — "Use when a product speaks MQTT, STOMP, or AMQP on the wire and QoS 1 / 2 redelivery, retained-message state, LWT, ack-mode, or broker-topology behavior needs a broker-backed test - including smoke-testing a new broker auth / ACL / persistence config". Both are present with concrete trigger phrases, matching the score-5 anchor exactly.

5 / 5

Trigger Term Quality

Natural terms a user would actually say are all present: "MQTT", "Mosquitto", "paho-mqtt", "QoS", "retained messages", "Last Will and Testament (LWT)", "shared subscriptions", "STOMP", "AMQP", "RabbitMQ", "Spring", "IoT", "M2M", "broker". It includes both abbreviation and expansion (LWT), client-library and broker implementation names, and adjacent-protocol synonyms — no meaningful natural-term gaps for this domain.

5 / 5

Distinctiveness Conflict Risk

Clear niche: broker-backed, wire-level protocol testing for MQTT/STOMP/AMQP, with triggers tied to "speaks MQTT, STOMP, or AMQP on the wire" and broker-behavior guarantees. This is well separated from generic messaging, HTTP/webhook, or raw-WebSocket skills, giving minimal conflict risk.

5 / 5

Total

20

/

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.

Reviewed

Table of Contents