jbaruch/shelly-duo-gu10
Ground truth for Shelly Duo GU10 RGBW smart bulb (Gen1): LAN HTTP REST contract, mDNS discovery (with the non-loopback-IPv4-bind gotcha), color/temp endpoints, off semantics, latency expectations. Language-agnostic facts; Kotlin/Ktor reference example.
88
86%
Does it follow best practices?
Impact
100%
1.28xAverage score across 3 eval scenarios
Passed
No known issues
Quality
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 an excellent skill description that is highly specific, includes rich trigger terms covering the product family and related technologies, explicitly states both what it does and when to use it, and occupies a very distinct niche. The description is detailed without being padded, uses third person voice correctly, and provides practical details like the 0.2s debounce interval and the mDNS binding gotcha.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: mDNS discovery, color/temperature/off endpoints, status probe, LAN debounce with specific timing (0.2s min-interval), and mentions the 'bind to non-loopback IPv4' gotcha. Very detailed and actionable. | 3 / 3 |
Completeness | Clearly answers both 'what' (controls Shelly bulbs via LAN HTTP REST with mDNS discovery, color/temperature/off endpoints, status probe, debounce) and 'when' (explicit 'Use when' clause covering controlling Shelly bulbs without cloud, mDNS discovery on JVM, or building low-latency IoT pipelines). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms: 'Shelly bulb', 'Shelly Duo', 'Shelly RGBW2', 'Shelly Color', 'smart bulbs', 'mDNS discovery', 'LAN', 'IoT pipeline', 'GU10', 'Gen1', 'JVM'. A user asking about any of these would naturally match this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely specific niche: Shelly Gen1 smart bulbs over LAN HTTP REST. This is unlikely to conflict with any other skill given the very specific hardware, protocol, and use case targeting. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A strong, highly actionable skill with excellent executable code examples covering the full Shelly Duo GU10 API surface, mDNS discovery with a critical platform-specific gotcha, and useful diagnostic commands. The main weaknesses are some unnecessary commentary/comparisons that pad the content, and the lack of an explicit end-to-end workflow with validation checkpoints (e.g., discover → verify → control → confirm). The anti-patterns section is a valuable addition.
Suggestions
Add a brief end-to-end workflow section (e.g., '1. Discover or set IP → 2. Verify reachability with /status → 3. Control → 4. Confirm state change') with explicit validation checkpoints.
Trim comparative commentary (Govee references, latency blame disclaimers) that doesn't directly help Claude control the bulb — move to a 'context' or 'notes' section if needed.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient with good information density, but includes some unnecessary commentary (e.g., 'the IoT-counterpart-of-choice', Govee comparisons, latency explanations about blaming Shelly, 'one less thing to break'). The 'off semantics' section explaining Govee differences is context Claude doesn't need unless asked. Still, most content earns its place. | 2 / 3 |
Actionability | Excellent executable code throughout: complete Kotlin client class with Ktor, full mDNS discovery function with the critical gotcha, curl diagnostic commands, shutdown hook pattern, and Gradle dependency. All code is copy-paste ready with concrete parameter ranges and endpoint specifications. | 3 / 3 |
Workflow Clarity | The skill covers multiple operations clearly (discovery, color control, diagnostics) but lacks an explicit sequenced workflow with validation checkpoints. For example, there's no 'first discover, then verify reachability, then control' sequence. The anti-patterns section is helpful but reactive rather than proactive. The isReachable method exists but isn't woven into a validate-then-act workflow. | 2 / 3 |
Progressive Disclosure | Content is well-organized with clear section headers and logical grouping, but everything is in a single monolithic file. The mDNS discovery code, Kotlin client, and diagnostic commands could be split into referenced files. For a skill of this length (~150 lines of substantive content), some separation would improve navigability. However, no bundle files exist to reference. | 2 / 3 |
Total | 9 / 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.
Reviewed
Table of Contents