embedded-review_skill

This skill performs dual-model embedded code reviews comparing Claude Code and Codex findings to detect memory, ISR, and interface hazards.
  • Python

2.5k

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/skills --skill embedded-review

  • _meta.json294 B
  • README.md4.6 KB
  • SKILL.md8.7 KB

Overview

This skill performs expert code review for embedded and firmware projects using a dual-model cross-review approach (Claude + Codex via ACP) to surface blind spots single-model reviews miss. It targets bare-metal MCUs, RTOS-based systems (FreeRTOS/Zephyr/ThreadX), embedded Linux, and mixed C/C++ firmware. Reviews prioritize memory safety, interrupt and concurrency hazards, hardware interface correctness, and common C/C++ anti-patterns.

How this skill works

The skill prepares a REVIEW_CONTEXT from the repository and diff, detects scope and critical paths, then runs either a single-model pass for small diffs or a dual-model cross-review for larger or sensitive changes. In dual-model mode it spawns two independent reviewers (Claude Code and Codex), waits for both results, and cross-compares findings into unified severity levels (P0–P3). Output includes actionable findings, risk assessment, suggested fixes, and a cross-review analysis showing consensus and disagreements.

When to use it

  • New features touching ISRs, DMA, boot, crypto, or NFC
  • Large diffs (>100 lines) or architecture changes
  • Pull requests modifying HAL/BSP, peripheral init, or concurrency primitives
  • Security-sensitive updates: firmware updates, secrets, debug interfaces
  • Quick checks for tiny patches or documentation changes (single-model)

Best practices

  • Provide target context: MCU, RTOS, compiler, and hardware dependencies
  • Run prepare-diff to build full REVIEW_CONTEXT before requesting review
  • Request dual-model cross-review for critical paths or >100-line changes
  • Prioritize fixing P0/P1 findings before merging; treat P2 as follow-ups
  • When models disagree, inspect the flagged lines and request human judgment

Example use cases

  • Review a PR that adds an ISR handler and DMA-based transfer
  • Audit firmware update path for signature/rollback issues
  • Assess RTOS API usage and potential priority-inversion or race conditions
  • Scan drivers for buffer overruns, alignment or DMA cache-coherency bugs
  • Cross-compare two independent reviewers on a major refactor of HAL layers

FAQ

Dual-model is used by default for diffs >100 lines or when you explicitly request higher assurance; small diffs use single-model for speed and cost savings.

How are severities mapped?

Findings are mapped to P0 (critical, block merge), P1 (high, fix before merge), P2 (medium, fix or follow-up), P3 (low, optional). Consensus between both models raises confidence.

Can I re-run review after fixes?

Yes. Re-run the review on the updated diff; for critical paths consider another dual-model pass to validate fixes.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational