Use when building IoT apps. Keywords: IoT, Internet of Things, sensor, MQTT, device, edge computing, telemetry, actuator, smart home, gateway, protocol, 物联网, 传感器, 边缘计算, 智能家居
39
37%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/domain-iot/SKILL.mdQuality
Discovery
37%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 description is essentially a keyword dump with no substantive explanation of what the skill does. While the trigger terms are comprehensive and well-chosen, the complete absence of concrete capabilities makes it impossible for Claude to understand what actions this skill enables. It reads more like a tag list than a functional description.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Generates MQTT client code, configures sensor data pipelines, designs device communication protocols, and scaffolds IoT application architectures.'
Expand the 'Use when' clause with explicit trigger scenarios, e.g., 'Use when the user needs to connect IoT devices, process sensor telemetry, set up MQTT messaging, or build edge computing pipelines.'
Move the keyword list to a secondary role and lead with a clear capability statement in third person voice describing what the skill does.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'building IoT apps' but provides no concrete actions—no mention of what the skill actually does (e.g., connect devices, parse telemetry data, configure MQTT brokers). It is entirely vague about capabilities. | 1 / 3 |
Completeness | The 'when' clause is present ('Use when building IoT apps') but extremely vague, and the 'what' is essentially missing—there is no description of what the skill actually does. Both components are very weak. | 1 / 3 |
Trigger Term Quality | The description includes a comprehensive list of natural keywords users would say: IoT, MQTT, sensor, edge computing, smart home, telemetry, actuator, gateway, and even Chinese equivalents. Good coverage of common variations. | 3 / 3 |
Distinctiveness Conflict Risk | The IoT domain keywords provide some distinctiveness and the skill is unlikely to conflict with general coding skills, but the lack of specific actions means it could overlap with any IoT-adjacent skill (e.g., an MQTT-specific skill or a smart home skill). | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable reference card for IoT domain constraints and Rust crate choices, with one useful MQTT code example. However, it reads more like a conceptual overview than actionable guidance — most content is in abstract tables without executable examples or clear workflows. The layered architecture references (Layer 1/2/3) add structure but also complexity without corresponding navigable content.
Suggestions
Add a concrete, step-by-step workflow for a common IoT task (e.g., 'Setting up an MQTT device with store-and-forward'), including validation checkpoints like testing broker connectivity and verifying message delivery.
Replace the abstract 'Critical Constraints' code blocks with executable Rust snippets showing retry-with-backoff, local buffering, or TLS configuration — these are the most actionable patterns for IoT development.
Remove redundancy between the 'Domain Constraints' table, 'Critical Constraints' section, and 'Trace to Layer 1' table — consolidate into a single reference with clear pointers to implementation details.
Complete the MQTT code example with missing imports and stub implementations for `read_sensor` and `handle_event` to make it truly copy-paste ready.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured with tables for quick scanning, but includes some redundancy (e.g., the 'Trace Down' and 'Trace to Layer 1' sections overlap significantly with the domain constraints table). The 'Critical Constraints' section repeats information already in the table above it in a less useful format. | 2 / 3 |
Actionability | The MQTT code example is concrete and nearly executable (missing `use std::time::Duration;` and undefined helper functions like `read_sensor` and `handle_event`), but most other guidance is abstract — tables listing patterns and crates without showing how to use them. The 'Critical Constraints' blocks are descriptive rather than instructive. | 2 / 3 |
Workflow Clarity | There is no clear multi-step workflow for building an IoT application. The content presents constraints and patterns as reference tables but never sequences them into a development process. For a domain involving OTA updates, firmware flashing, and network-unreliable deployments, the absence of any validation checkpoints or step-by-step process is a significant gap. | 1 / 3 |
Progressive Disclosure | The 'Related Skills' table references other skills (domain-embedded, m07-concurrency, etc.), providing some navigation. However, with no bundle files provided, these references are unverifiable. The content itself is somewhat monolithic — the constraints, patterns, and code could benefit from clearer separation, and the layered references (Layer 1, 2, 3) add conceptual overhead without clear navigation paths. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
fa60f79
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.