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.

Quality

47%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./docs/v19.7/configuration/agent/skills_external/antigravity-awesome-skills-main/skills/arm-cortex-expert/SKILL.md

Quality

Content

62%

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

This is a comprehensive embedded systems skill with strong safety-critical patterns and clear workflow guidance. However, it suffers from being overly verbose in places (explaining concepts Claude knows) and providing incomplete code examples that describe patterns rather than delivering fully executable implementations. The content would benefit from splitting detailed reference material into separate files and providing complete, compilable driver examples.

Suggestions

Replace pseudocode patterns with complete, compilable driver implementations (e.g., full SPI driver with init, ISR, and usage example)

Move the architecture comparison table and platform-specific gotchas to a separate PLATFORMS.md reference file

Remove explanatory text about what memory barriers are and why they matter - focus on the implementation patterns only

Add complete mmio_read()/mmio_write() helper function implementations rather than just describing them

Dimension	Reasoning	Score
Conciseness	The skill contains valuable embedded-specific knowledge but includes some redundant explanations (e.g., explaining what memory barriers are, listing platform features Claude likely knows). The architecture comparison table and some platform descriptions could be more condensed.	2 / 3
Actionability	Provides concrete patterns and code snippets but many are incomplete or pseudocode-like (e.g., SPI driver example describes pattern without full implementation, barrier helpers described but not fully implemented). The 'Example: SPI Driver' section lists APIs but lacks a complete, copy-paste ready driver.	2 / 3
Workflow Clarity	The workflow section provides clear 6-step sequencing with validation. Safety-critical patterns include explicit validation steps (cache maintenance before/after DMA, address validation in debug builds). The DMA/cache coherency section has clear 'Best to Worst' ordering with explicit checkpoints.	3 / 3
Progressive Disclosure	References `resources/implementation-playbook.md` for detailed examples but the main file is quite long (~300 lines) with content that could be split into separate reference files (e.g., platform-specific details, architecture comparison table, safety patterns). The structure is good but content organization could be improved.	2 / 3
	Total	9 / 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.

This description reads more like a resume or persona description than a skill description. It focuses on credentials ('Senior', 'Decades of experience') and expertise areas rather than concrete actions Claude will perform. The complete absence of a 'Use when...' clause and the use of first-person implied voice ('specializing in') significantly weakens its utility for skill selection.

Suggestions

Add an explicit 'Use when...' clause with trigger scenarios like 'Use when writing firmware, debugging embedded systems, working with ARM Cortex-M microcontrollers, or optimizing low-level C code'

Replace credential language with action verbs: instead of 'specializing in firmware development', use 'Writes and debugs firmware, develops peripheral drivers, optimizes memory usage'

Include common user phrases like 'embedded C', 'bare metal programming', 'RTOS', 'microcontroller code', 'hardware abstraction layer' to improve trigger term coverage

Dimension	Reasoning	Score
Specificity	Names the domain (embedded/firmware) and lists technical areas (memory barriers, DMA/cache coherency, interrupt-driven I/O, peripheral drivers), but these are expertise areas rather than concrete actions the skill performs. No action verbs like 'writes', 'debugs', 'optimizes' are used.	2 / 3
Completeness	Describes expertise areas (what the persona knows) but lacks any 'Use when...' clause or explicit trigger guidance. Does not clearly answer 'what does this do' in terms of actions, and completely missing 'when should Claude use it'.	1 / 3
Trigger Term Quality	Includes relevant technical terms users might search for (ARM Cortex-M, Teensy, STM32, nRF52, SAMD, firmware, driver, DMA), but missing common variations like 'embedded C', 'bare metal', 'RTOS', 'microcontroller programming', or simpler terms like 'MCU'.	2 / 3
Distinctiveness Conflict Risk	The specific microcontroller families (Teensy, STM32, nRF52, SAMD) and ARM Cortex-M focus provide some distinctiveness, but 'firmware and driver development' is broad enough to potentially overlap with other embedded or systems programming skills.	2 / 3
	Total	7 / 12 Passed

Validation

90%

Warnings & errors only

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
metadata_version	'metadata.version' is missing	Warning

	Total	10 / 11 Passed

Repository: duclm1x1/Dive-Ai
Commit: 20ba150

Reviewed: 5 months ago

Table of Contents

Discovery Implementation Validation

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.