CtrlK
BlogDocsLog inGet started
Tessl Logo

arm-cortex-expert

Senior embedded software engineer specializing in firmware and driver development for ARM Cortex-M microcontrollers (Teensy, STM32, nRF52, SAMD). Decades of experience writing reliable, optimized, and maintainable embedded code with deep expertise in memory barriers, DMA/cache coherency, interrupt-driven I/O, and peripheral drivers.

32

Quality

27%

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 ./.agent/skills/arm-cortex-expert/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

22%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill reads more like a persona/role definition than an actionable skill document. It extensively lists capabilities, platforms, and topics Claude should know about but provides no concrete code examples, specific commands, or executable workflows. The safety-critical patterns section is just a header followed by sub-skill links with no inline guidance, and the core instructions are generic platitudes rather than specific embedded development procedures.

Suggestions

Add at least 2-3 concrete, executable code examples for common tasks (e.g., a complete DMA setup with cache coherency, an interrupt-driven UART driver skeleton) to dramatically improve actionability.

Replace the generic 'Instructions' bullets with a specific workflow for common embedded tasks, including validation steps (e.g., 'After writing a peripheral driver: 1. Verify register addresses against datasheet, 2. Check ISR priority conflicts, 3. Validate DMA buffer alignment').

Remove or drastically condense the Knowledge Base and Core Competencies sections — these describe what Claude already knows. Replace with specific patterns, gotchas, or decision trees that add novel value (e.g., 'When choosing between DMA and interrupt-driven I/O, use this decision matrix...').

Add concrete examples of safety-critical patterns inline (e.g., a memory barrier usage example, a W1C register access pattern) rather than only linking to sub-skills, so the main skill provides immediate actionable value.

DimensionReasoningScore

Conciseness

The skill includes some unnecessary sections (e.g., 'Use this skill when' / 'Do not use this skill when' are tautological and add no value). The Knowledge Base and Core Competencies sections are largely listing things Claude already knows about embedded development rather than providing novel, actionable guidance. However, the overall structure is reasonably organized and not excessively verbose.

2 / 3

Actionability

The skill contains zero executable code, no concrete commands, and no specific examples. It reads as a role description and capability listing rather than actionable instructions. Phrases like 'Apply relevant best practices and validate outcomes' and 'Deliver complete, compilable firmware' describe desired outcomes without showing how to achieve them.

1 / 3

Workflow Clarity

There is no clear multi-step workflow, no validation checkpoints, and no sequenced process for any embedded development task. The 'Instructions' section has four bullet points that are generic platitudes ('Clarify goals, constraints, and required inputs') rather than concrete workflow steps. For a skill involving safety-critical embedded patterns, the absence of any verification or validation workflow is a significant gap.

1 / 3

Progressive Disclosure

The skill does reference sub-skills and a resources/implementation-playbook.md file with clear one-level-deep links, which is good structure. However, since no bundle files were provided, we cannot verify these references exist. The main SKILL.md itself contains a lot of inline content (Knowledge Base, Core Competencies, Advanced Topics) that could arguably be in a separate reference file, while the actual actionable content is thin.

2 / 3

Total

6

/

12

Passed

Description

32%

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 reads like a resume or persona definition rather than a functional skill description. It uses first-person-adjacent framing ('Senior embedded software engineer specializing in...') instead of third-person action-oriented language, lists expertise areas rather than concrete actions, and completely lacks a 'Use when...' clause to guide skill selection. The technical keywords provide some value for matching but are insufficient without explicit trigger guidance.

Suggestions

Add an explicit 'Use when...' clause with trigger conditions, e.g., 'Use when the user asks about firmware development, microcontroller programming, ARM Cortex-M code, or embedded C for Teensy/STM32/nRF52/SAMD boards.'

Replace the persona framing with concrete action verbs describing what the skill does, e.g., 'Writes and reviews embedded C/C++ firmware, implements peripheral drivers, debugs DMA/interrupt issues, and optimizes code for ARM Cortex-M microcontrollers.'

Add common user-facing trigger terms like 'embedded C', 'bare-metal', 'RTOS', 'GPIO', 'SPI', 'I2C', 'UART', and 'register-level programming' to improve keyword coverage.

DimensionReasoningScore

Specificity

Names the domain (embedded/firmware development) and lists technical areas like memory barriers, DMA/cache coherency, interrupt-driven I/O, and peripheral drivers, but these read more like expertise areas than concrete actions the skill performs. No action verbs like 'writes', 'debugs', 'generates' are used to describe what the skill actually does.

2 / 3

Completeness

The description addresses 'what' only partially (describes expertise areas rather than concrete actions) and completely lacks any 'when' clause or explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the weak 'what' brings it down to 1.

1 / 3

Trigger Term Quality

Includes relevant technical keywords like ARM Cortex-M, Teensy, STM32, nRF52, SAMD, DMA, firmware, and driver development that users might mention. However, it misses common user-facing terms like 'embedded C', 'RTOS', 'bare-metal', 'GPIO', 'SPI', 'I2C', 'UART', or 'flashing firmware' that users would naturally say.

2 / 3

Distinctiveness Conflict Risk

The embedded/microcontroller focus is fairly specific and distinguishes it from general software development skills. However, the broad framing as a 'senior embedded software engineer' persona could overlap with other embedded or hardware-related skills, and the lack of explicit trigger conditions increases conflict risk.

2 / 3

Total

7

/

12

Passed

Validation

81%

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

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

frontmatter_unknown_keys

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

Warning

Total

9

/

11

Passed

Repository
Dokhacgiakhoa/antigravity-ide
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.