CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

iot-security

IoT device security reconnaissance — firmware extraction, embedded analysis, protocol identification, default credential checking, vulnerability scanning, device fingerprinting.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./packages/decepticon/decepticon/skills/standard/recon/iot-security/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%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-organized command reference with broad topical coverage, but it functions as a monolithic dump rather than a curated skill: some tools are fabricated, generic security knowledge is restated, and there is no progressive disclosure into reference files despite the volume of material.

Suggestions

Replace fabricated tools (iot-scanner, iot-vuln-scanner, zigbee-scan, zwave-scan, zwave-nodes, modbus-read) with real equivalents (e.g. KillerBee for Zigbee, mbpoll for Modbus, nmap NSE scripts) or bundle the referenced username/password lists.

Split protocol-specific (MQTT/CoAP/Modbus), wireless (Zigbee/Z-Wave/BLE), and cloud sections into references/ files, keeping SKILL.md as a concise overview with clearly signaled links.

Trim the introductory paragraph and the generic vulnerability/hardening checklists (Sections 6 and 9) that restate knowledge Claude already has, and add explicit sequencing with validation checkpoints for the firmware extraction and analysis workflow.

DimensionReasoningScore

Conciseness

The bulk is lean, commented commands, but the opening paragraph ('IoT (Internet of Things) device security reconnaissance focuses on...'), the generic vulnerability list in Section 6, and the generic hardening checklists in Section 9 restate knowledge Claude already has and could be trimmed.

3 / 5

Actionability

Most sections give real, executable commands (nmap, binwalk, mosquitto_sub, coap-client, hydra), but several tools appear fabricated or non-standard (iot-scanner, iot-vuln-scanner, zigbee-scan, zwave-scan, zwave-nodes, modbus-read), and the hydra example references common_usernames.txt/common_passwords.txt files that are not provided — more than minor gaps.

3 / 5

Workflow Clarity

The numbered sections imply a rough recon sequence (discovery → firmware extraction → analysis → protocols → exploitation), but the body is a catalog by topic rather than a sequenced workflow, with no explicit decision guidance or validation checkpoints (e.g., verifying extracted firmware integrity or confirming device authorization before testing).

3 / 5

Progressive Disclosure

Sections are well-organized with clear headers, but this is a 350-line monolithic SKILL.md with no reference files at all; protocol-specific, wireless, and cloud material clearly belongs in separate reference files loaded on demand.

3 / 5

Total

12

/

20

Passed

Description

71%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 specific, well-scoped description that clearly communicates the skill's capabilities with concrete action verbs. Its main weakness is the absence of any 'when to use' trigger guidance, and some natural trigger terms are relegated to metadata rather than the description itself.

Suggestions

Append an explicit trigger clause, e.g. 'Use when assessing IoT devices, smart cameras, or embedded hardware, or when the user mentions firmware, MQTT, CoAP, or Modbus.'

Move a few natural synonyms from metadata.when_to_use (smart devices, embedded devices, MQTT/CoAP/Modbus) into the description to improve trigger term coverage.

DimensionReasoningScore

Specificity

The description lists six concrete actions — 'firmware extraction, embedded analysis, protocol identification, default credential checking, vulnerability scanning, device fingerprinting' — matching the anchor for multiple specific concrete actions with comprehensive coverage of the domain.

5 / 5

Completeness

The 'what' is clearly and concretely stated, but there is no 'Use when...' clause or equivalent trigger guidance in the description; the judging guidelines cap completeness at 3 for this.

3 / 5

Trigger Term Quality

Good natural keyword coverage ('IoT device security', 'firmware extraction', 'default credential checking', 'device fingerprinting'), but a few natural terms users would say (smart devices, MQTT/CoAP, embedded devices) are missing from the description itself and only appear in metadata.

4 / 5

Distinctiveness Conflict Risk

'IoT device security reconnaissance' carves out a clear niche with distinct triggers, but 'vulnerability scanning' and 'default credential checking' are general pentest terms creating minor overlap risk with broader security scanning skills.

4 / 5

Total

16

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

PurpleAILAB/Decepticon

Path

packages/decepticon/decepticon/skills/standard/recon/iot-security/SKILL.md

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.