Skip to main content
Back to the field guide

A field guide to the /volt-firmware skill

AI Firmware Architecture Spec for MCUs

Most embedded projects start as bare-metal demos. /volt-firmware scaffolds RTOS task structure, peripheral init, power management, comms stack, OTA, and CI for ESP-IDF, STM32, Zephyr, Arduino.

Volt · Embedded/IoT8 min readFebruary 16, 2026

Embedded firmware projects often start as bare-metal demos. A blink, a UART hello, a sensor read. The demo runs. Six months later, the team has a tangle of single-file C with no task structure, no power management, no OTA, and a build that only works on the lead engineer's laptop. Adding a feature means understanding the whole tangle, and adding a feature without breaking timing is a whisper-thin guess. The cost is paid in the rewrite that happens when the device has to ship to customers.

Firmware done well has structure from day one. RTOS tasks with planned stack sizes, peripheral init in a defined sequence, a power management state machine that names the modes the device transitions through, a communication stack scoped to the protocol the product uses, OTA so updates do not require a USB cable, and CI that builds reproducibly. The discipline takes a focused effort upfront and pays back every time the team adds a feature or chases a power bug. The /volt-firmware skill produces the foundation calibrated to the target MCU and framework.

What firmware foundations require

Six layers. RTOS task structure: tasks named for their role (sensor, network, UI), with stack sizes calibrated to actual usage rather than guesses. Peripheral init: the boot sequence that brings up clocks, GPIO, peripherals in the right order with the right error handling. Power management: state machine for active, idle, sleep, deep sleep, with the wake sources defined per state. Communication stack: BLE GATT services, MQTT topics, or serial protocol depending on the product. OTA: signed update images, dual-bank or A/B partitions, rollback on boot failure. CI: reproducible builds for the target, ideally with hardware-in-the-loop test if available.

How /volt-firmware works

The skill detects the target MCU and framework (ESP-IDF for Espressif, STM32 HAL for STMicro, Zephyr for cross-vendor RTOS, Arduino for prototyping) and produces the scaffolding for each layer. ESP-IDF gets FreeRTOS tasks, ESP partition table for OTA, BLE NimBLE or Wi-Fi TLS as appropriate. STM32 gets HAL init in the right order, FreeRTOS or bare-metal scheduler depending on need, ST OTA or custom dual-bank. Zephyr gets the device tree, Kconfig, and the canonical Zephyr OTA. Arduino is supported for prototypes but the skill flags the production limitations.

Stack overflows are the most common embedded crash and the hardest to diagnose without watermarking. /volt-firmware enables stack high-water-mark tracking by default so production telemetry can surface tasks running close to overflow before the crash.

Tonone's /volt-firmware skill scaffolds embedded firmware with RTOS tasks, peripheral init, power management, comms stack, OTA, and CI calibrated to the target MCU.

When to use /volt-firmware

/volt-firmware is the right call when starting a new firmware project on a target MCU and the team wants production-ready foundations rather than a bare-metal demo. Skip it for purely throwaway prototypes. For driver-level work on a specific peripheral, /volt-driver is the right call. For OTA-specific design, /volt-ota covers the update flow. For power management deep dive, /volt-power produces the audit.

CapabilityTononeGeneralist chatbotCursor / Copilot
RTOS task structure with stack sizesYes, calibrated to usageSingle main loopVariable
Power management state machineYes, modes + wake sourcesAlways-onVariable
OTA with signed images and rollbackYes, dual-bank or A/BNot in scopeVariable
Reproducible CI buildYes, container-basedNot in scopeVariable
Stack watermark + crash telemetryYes, by defaultNot in scopeVariable

/volt-firmware produces the foundation. /volt-driver for peripheral drivers. /volt-ota for OTA system design. /volt-power for power management audit.

Install

/volt-firmware ships with the Volt agent in Tonone for Claude Code. Install Tonone, invoke /volt-firmware, and the skill produces the firmware foundation for the chosen MCU.

1. Add to marketplace

$ claude plugin marketplace add tonone-ai/tonone

2. Install Volt

$ claude plugin install volt@tonone-ai

Embedded products that ship reliably are built on the right foundation. The skill is built so the foundation is the default.

Frequently asked questions

What does /volt-firmware do?
It scaffolds firmware with RTOS task structure, peripheral init sequence, power management state machine, communication stack, OTA update client, and CI build configuration.
What frameworks does /volt-firmware support?
ESP-IDF, STM32 HAL, Zephyr, and Arduino. The skill detects the chosen framework or proposes one for greenfield.
When should I use /volt-firmware?
When starting a new firmware project on a target MCU and you want production-ready foundations. Skip for throwaway prototypes.
Does /volt-firmware handle OTA?
Yes. Signed update images, dual-bank or A/B partitions, rollback on boot failure. The implementation is calibrated to the MCU's flash layout.
How do I install /volt-firmware?
Install Tonone for Claude Code via tonone.ai/get-started. /volt-firmware ships with the Volt agent. Tonone is free and MIT-licensed.
Is /volt-firmware free?
Yes. Tonone is MIT-licensed. The only cost is Claude Code token usage.

Pairs well with