arm-cortex-expert

tessl i github:sickn33/antigravity-awesome-skills --skill 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.

59%

Overall

Validation — 81%

Implementation — 63%

Activation — 33%

SKILL.md

Review

Evals

Validation

81%

Warnings & errors only

Criteria	Description	Result
description_trigger_hint	Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...')	Warning
metadata_version	'metadata.version' is missing	Warning
license_field	'license' field is missing	Warning

	Total	13 / 16 Passed

Implementation

63%

This is a comprehensive embedded systems skill with strong safety-critical patterns and clear workflow guidance. The main weaknesses are verbosity (could trim platform descriptions and architecture tables) and incomplete actionability (patterns described but not always with full executable examples). The progressive disclosure could be improved by moving detailed platform-specific content to separate files.

Suggestions

Add complete, compilable driver examples (e.g., full SPI sensor driver with init, ISR, and usage) rather than pattern descriptions

Move the architecture comparison table and platform-specific gotchas to separate reference files (e.g., PLATFORMS.md, ARCHITECTURE.md) to reduce main file length

Trim explanatory text that describes what concepts are (e.g., 'ARM Cortex-M7 has weakly-ordered memory') and focus on the actionable patterns

Convert the SPI driver example section into actual executable code with complete init(), transfer(), and ISR implementations

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 for memory barriers, DMA alignment, and critical sections, but many examples are incomplete or pseudocode-like (e.g., SPI driver section describes patterns without full executable code). The 'Example: SPI Driver' section lists APIs but doesn't provide a complete working driver.	2 / 3
Workflow Clarity	The workflow section provides clear 6-step sequencing with validation. Safety-critical patterns include explicit validation steps (address validation in debug builds, cache maintenance before/after DMA). 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, which is good progressive disclosure. However, the main file is quite long (~300 lines) with substantial inline content that could be split into separate reference files (e.g., platform-specific details, architecture comparison table).	2 / 3
	Total	9 / 12 Passed

Activation

33%

This description reads like a professional bio rather than a functional skill description. It emphasizes credentials ('Senior', 'Decades of experience') and knowledge areas but fails to specify concrete actions the skill performs or when Claude should select it. The technical keywords provide some value for matching, but the lack of actionable verbs and explicit trigger guidance significantly limits its effectiveness for skill selection.

Suggestions

Replace credential-focused language with action verbs describing what the skill does (e.g., 'Writes firmware for ARM Cortex-M microcontrollers, implements peripheral drivers, debugs interrupt handlers').

Add an explicit 'Use when...' clause with trigger scenarios (e.g., 'Use when working with Teensy, STM32, nRF52, or SAMD boards, or when the user mentions embedded C, microcontroller programming, or hardware drivers').

Remove first-person implied voice ('Senior embedded software engineer') and use third-person action-oriented phrasing ('Develops firmware', 'Implements drivers').

Dimension	Reasoning	Score
Specificity	Names the domain (embedded/firmware) and mentions specific areas like 'memory barriers, DMA/cache coherency, interrupt-driven I/O, and peripheral drivers', but these are technical concepts rather than concrete actions the skill performs. No verbs describing what it actually does.	2 / 3
Completeness	Describes expertise areas (what it knows) but never explains what actions it performs or when Claude should use it. No 'Use when...' clause or equivalent trigger guidance. Reads like a resume rather than a skill description.	1 / 3
Trigger Term Quality	Includes good technical keywords users might search for (Teensy, STM32, nRF52, SAMD, ARM Cortex-M, firmware, DMA), but missing common user phrases like 'microcontroller code', 'embedded C', or action-oriented terms like 'debug', 'flash', 'port'.	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 general embedded or hardware skills.	2 / 3
	Total	7 / 12 Passed

Reviewed

15 days ago

Table of Contents

Validation Implementation Activation

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.