CtrlK
BlogDocsLog inGet started
Tessl Logo

firmware-analyst

Expert firmware analyst specializing in embedded systems, IoT security, and hardware reverse engineering.

45

Quality

47%

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

Fix and improve this skill with Tessl

tessl review fix ./plugins/AI-Agents-Safe-Coding-Skills/skills/firmware-analyst/SKILL.md

The canonical home for this skill is firmware-analyst in administrakt0r/AI-Agents-Safe-Coding-Skills

SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is rich in executable commands across a clear phased workflow, but it is padded with concepts Claude already knows, lacks validation checkpoints for destructive acquisition/extraction steps, and references a missing playbook file. The opening markdown is also structurally broken (an orphan closing code fence).

Suggestions

Remove or move to a reference file the explanatory vulnerability-class and tool-proficiency one-liners Claude already knows; keep only commands and skill-specific guidance (e.g. binwalk v3 entropy behavior, Firmadyne script order).

Insert validation checkpoints between phases, e.g. "Confirm binwalk extracted a usable rootfs (check ./extracted/squashfs-root) before Phase 3", and add a verify step for destructive dd/chip-off acquisition.

Fix the broken opening code fence and either create the referenced playbook under ./references/ (not resources/) or remove the dangling pointer to a non-existent file.

DimensionReasoningScore

Conciseness

Noticeably verbose: the "Common Vulnerability Classes" and "Tool Proficiency" sections re-explain concepts Claude already knows (stack overflow, format strings, what Ghidra/IDA Pro are), adding padded one-liner descriptions that don't earn their tokens.

2 / 5

Actionability

Mostly executable guidance with copy-paste-ready commands (binwalk -eM, unsquashfs, QEMU chroot, Firmadyne scripts); minor gaps like placeholder vendor URLs and an illustrative exploit.c compile line keep it just below fully executable.

4 / 5

Workflow Clarity

A phased workflow (Identification → Extraction → File System → Binary) exists, but validation checkpoints are absent between phases; because acquisition/extraction are destructive operations, workflow clarity is capped at 3 per the rubric.

3 / 5

Progressive Disclosure

No bundle files exist, yet the body references a non-existent "resources/implementation-playbook.md" (wrong directory); large reference-style catalogs (tool lists, vulnerability taxonomies, templates) are inlined rather than split into separate files.

2 / 5

Total

11

/

20

Passed

Description

48%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 establishes a clear, distinct niche but reads as a persona label rather than an action-oriented trigger. It lacks any "Use when..." guidance and enumerates no concrete capabilities, capping both specificity and completeness.

Suggestions

Rewrite in third person with concrete verbs, e.g. "Extracts, analyzes, and reverse-engineers firmware from embedded and IoT devices; dumps SPI/NAND flash and emulates binaries with QEMU."

Add an explicit "Use when..." trigger clause naming natural phrases like firmware analysis, .bin files, firmware extraction, IoT security review, or hardware reverse engineering.

Include common synonyms and file extensions (firmware, .bin, .img, flash dump, firmware RE) to improve trigger-term coverage.

DimensionReasoningScore

Specificity

Names the domain ("firmware analyst specializing in embedded systems, IoT security, and hardware reverse engineering") but lists no concrete actions — it describes a persona rather than verbs like extracting, dumping, or analyzing firmware.

2 / 5

Completeness

A clear "what" (firmware/embedded/IoT/hardware RE) is conveyed, but there is no "Use when..." clause or equivalent explicit trigger guidance, so completeness is capped at 3 per the rubric guideline.

3 / 5

Trigger Term Quality

Relevant natural keywords are present (firmware, IoT security, embedded systems, hardware reverse engineering) but missing common variations and synonyms users might say (.bin, firmware extraction, dumping firmware).

3 / 5

Distinctiveness Conflict Risk

The firmware/IoT/hardware-reverse-engineering niche is clearly distinct from most skills with only minor overlap risk against a generic security or reverse-engineering skill.

4 / 5

Total

12

/

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.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
administrakt0r/AI-Agents-Safe-Coding-Skills
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.