Agent skill

Driver Review

by FastLED in FastLED/FastLED

Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations.

MITAuto-check passedDevelopment

Install Driver Review

skills CLI
$ npx skills add FastLED/FastLED --skill driver-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install FastLED/FastLED driver-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/FastLED/FastLED.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/driver-review .claude/skills/driver-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
driver-review
GitHub stars
7.5k
Token cost
~3.1k tokens
SKILL.md length
762 words
Files
1
Skills in repo
23
Repo updated
First seen
Licence
MIT

At a glance

Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations.

  • Works in 9 steps: DMA Safety → Interrupt Safety → Peripheral Register Access → …
  • Reviewing LED drivers
  • SKILL.md covers Your Task, What Counts as Driver Code, Architecture and File Structure for New…, plus 8 more sections
  • Calls git

What it does

Driver Review is an agent skill from FastLED/FastLED. Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations. Use when writing, modifying, or reviewing LED drivers, SPI/I2S/RMT/UART/PARLIO/LCDCAM peripherals, GPIO configuration, or peripheral mock code.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Embedded systems. The repository describes itself as: The FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r We'd like to use github… The licence is MIT.

When your agent uses it

  • Reviewing LED drivers
  • SPI/I2S/RMT/UART/PARLIO/LCDCAM peripherals
  • GPIO configuration
  • Peripheral mock code

Example prompts

  • “/driver-review”

Workflow steps

9 steps, taken from the step headings in SKILL.md.

  1. DMA Safety
  2. Interrupt Safety
  3. Peripheral Register Access
  4. Timing Constraints
  5. Memory Safety
  6. Channel Engine Patterns (FastLED-specific)
  7. Peripheral Mock Rules (CRITICAL)
  8. Power and Reset
  9. Multi-Platform Considerations

What it can do on your machine

Read from SKILL.md and the folder at commit ce225ed. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Driver Review loads about 3.1k tokens when it runs. Until then it costs about 85 tokens; SKILL.md has 762 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~85
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from FastLED/FastLED at commit ce225ed, republished under its MIT licence (© FastLED). 762 words, ~3,133 tokens.

Download SKILL.mdSave it as .claude/skills/driver-review/SKILL.md (or your agent's skills folder).
name
driver-review
description
Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations. Use when writing, modifying, or reviewing LED drivers, SPI/I2S/RMT/UART/PARLIO/LCD_CAM peripherals, GPIO configuration, or peripheral mock code.
disable-model-invocation
true

Hardware Driver Review & Implementation Guide

Review and implement hardware driver code changes for embedded-specific safety and correctness issues.

Your Task

  1. Run git diff --cached and git diff to see all changes
  2. Identify files that are hardware driver code (see "What Counts as Driver Code" below)
  3. For reviews: Check ALL driver code changes against the Review Rules below
  4. For implementations: Follow the Implementation Guide below
  5. Fix straightforward violations directly
  6. Report summary of all findings

What Counts as Driver Code

Files matching these patterns:

  • src/platforms/** — Platform-specific implementations
  • src/fl/channels/** — LED channel engine and DMA pipeline
  • **/drivers/** — Hardware driver implementations
  • Files containing: DMA buffers, SPI/I2S/RMT/UART/PARLIO peripheral access, GPIO configuration, interrupt handlers, timer configuration

Part 1: Review Rules

1. DMA Safety
  • DMA buffers allocated with MALLOC_CAP_INTERNAL | MALLOC_CAP_DMA
  • DMA buffers are 4-byte aligned (use __attribute__((aligned(4))) or aligned allocator)
  • No stack-allocated DMA buffers (must be heap or static)
  • DMA descriptors in internal SRAM (not PSRAM/SPIRAM)
  • Cache coherence handled: esp_cache_msync() or non-cacheable memory for DMA
  • DMA transfer size within hardware limits
  • Buffer lifetime extends beyond DMA completion (no use-after-free)
2. Interrupt Safety
  • ISR functions marked with IRAM_ATTR (ESP32) or proper section attributes
  • No heap allocation (malloc, new, fl::vector) inside ISRs
  • No mutex/semaphore take with blocking timeout in ISRs (use portMAX_DELAY = 0 only)
  • No printf, FL_DBG, FL_WARN, or logging in ISRs
  • No flash access from ISRs (all ISR code and data in IRAM/DRAM)
  • ISR-safe queue operations only (xQueueSendFromISR, not xQueueSend)
  • Critical sections use proper primitives (portENTER_CRITICAL_ISR not portENTER_CRITICAL)
  • ISR handlers return correct value (true if higher-priority task woken)
3. Peripheral Register Access
  • Registers accessed through volatile pointers or HAL functions
  • No read-modify-write races on shared registers (use atomic or critical section)
  • Peripheral clock enabled before register access
  • Peripheral properly initialized before use and cleaned up on teardown
  • GPIO matrix/IOMUX configured correctly for peripheral signals
4. Timing Constraints
  • SPI/I2S/RMT clock calculations match LED protocol requirements
  • Reset timing meets protocol minimums (WS2812: >280us, SK6812: >80us)
  • No blocking waits in time-critical paths
  • Watchdog fed in long-running operations
  • vTaskDelay(1) or yield() in busy loops to prevent watchdog reset
5. Memory Safety
  • Buffer sizes checked before DMA transfer setup
  • No buffer overflows in encoding functions (bounds checking on output buffer)
  • Encoding output size calculated correctly (e.g., wave8: 8 SPI bits per LED bit)
  • Chunk sizes aligned to hardware requirements (SPI: 4-byte aligned)
6. Channel Engine Patterns (FastLED-specific)
  • show() waits for poll() == READY before starting new frame
  • No branching on intermediate states (DRAINING, STREAMING) in wait loops
  • Channel released after transmission complete (frees peripheral for next channel)
  • State machine handles all transitions (no stuck states)
  • Error recovery path exists (timeout, reset to IDLE)
Show full SKILL.md (328 more words)Show less
7. Peripheral Mock Rules (CRITICAL)
  • NO background threads — mock must be fully synchronous
  • NO wall-clock timing (fl::micros(), sleep_for) — use mSimulatedTimeUs
  • NO mutex/condition_variable — single-threaded, no synchronization needed
  • Synchronous callback pump via pumpDeferredCallbacks() with re-entrancy guard
  • waitDone() returns instantly — never polls or sleeps
  • reset() clears ALL state — called between test cases for isolation
  • Transmitted data captured in history vector for test inspection
  • Singleton via fl::Singleton<Impl>
8. Power and Reset
  • Brown-out detection configured if needed
  • Peripheral reset on initialization (clean state)
  • GPIO pins set to safe state on driver teardown
  • Power domains managed correctly (light sleep compatibility)
9. Multi-Platform Considerations
  • Platform guards (#ifdef ESP32, #ifdef FL_IS_ARM) correct and complete
  • No platform-specific types leaking into shared headers
  • Fallback/no-op implementations for unsupported platforms
  • Integer types match platform expectations (see src/platforms/*/int.h)

Part 2: Implementation Guide

Architecture

FastLED's driver stack has three layers:

IChannelDriver              (driver.h — show/poll state machine)
  └─ ChannelEngine*         (groups channels by timing, iterates chipset groups)
      └─ IPeripheral        (virtual interface — real HW or mock)
          ├─ PeripheralEsp  (real ESP-IDF calls)
          └─ PeripheralMock (synchronous test simulation)

File Structure for New Peripheral foo

src/platforms/esp/32/drivers/foo/
  ├─ ifoo_peripheral.h              # Virtual interface (no ESP-IDF types)
  ├─ foo_peripheral_esp.h           # Real hardware implementation
  ├─ foo_peripheral_mock.h          # Mock class declaration
  ├─ foo_peripheral_mock.cpp.hpp    # Mock implementation (synchronous)
  └─ channel_driver_foo.cpp.hpp     # Channel driver using IFooPeripheral

tests/platforms/esp/32/drivers/foo/
  ├─ foo_peripheral_mock.cpp        # Mock peripheral unit tests
  └─ channel_driver_foo.cpp         # Driver integration tests

Reference implementations:

  • I2S: src/platforms/esp/32/drivers/i2s/
  • LCD_CAM: src/platforms/esp/32/drivers/lcd_cam/
  • PARLIO: src/platforms/esp/32/drivers/parlio/

Peripheral Interface

Define the virtual interface in ifoo_peripheral.h:

  • No ESP-IDF types — use void*, u16*, basic types only
  • All methods FL_NOEXCEPT override
  • Buffer management with 64-byte alignment (DMA requirement)
  • Time simulation: getMicroseconds(), delay(ms)
  • Callback registration: registerCallback(void* fn, void* ctx)

Peripheral Mock Implementation

Required Members
cpp
// Lifecycle
bool mInitialized, mEnabled, mBusy;
size_t mTransmitCount;
FooConfig mConfig;

// ISR callback
void* mCallback;
void* mUserCtx;

// Simulation settings
u32 mTransmitDelayUs;
bool mTransmitDelayForced;
bool mShouldFailTransmit;

// Test inspection
fl::vector<TransmitRecord> mHistory;

// Pending state
size_t mPendingTransmits;

// Simulated time (deterministic — advances only via delay() calls)
u64 mSimulatedTimeUs;

// Synchronous callback pump
bool mFiringCallbacks;            // Re-entrancy guard
size_t mDeferredCallbackCount;    // Pending callbacks to fire
Core Pattern: transmit() → pump → fireCallback()

transmit() — Queue + pump:

cpp
bool transmit(const u16* buffer, size_t size_bytes) {
    if (!mInitialized || mShouldFailTransmit) return false;

    // Capture data for test inspection
    TransmitRecord record;
    record.buffer_copy.resize(size_bytes / 2);
    fl::memcpy(record.buffer_copy.data(), buffer, size_bytes);
    record.size_bytes = size_bytes;
    record.timestamp_us = mSimulatedTimeUs;
    mHistory.push_back(fl::move(record));

    // Queue + fire synchronously
    mTransmitCount++;
    mBusy = true;
    mPendingTransmits++;
    mDeferredCallbackCount++;
    pumpDeferredCallbacks();
    return true;
}

waitDone() — Instant check, never polls:

cpp
bool waitDone(u32 timeout_ms) {
    if (!mInitialized) return false;
    (void)timeout_ms;  // Not used — synchronous mock
    if (mPendingTransmits == 0) { mBusy = false; return true; }
    return false;
}

pumpDeferredCallbacks() — Re-entrant safe:

cpp
void pumpDeferredCallbacks() {
    if (mFiringCallbacks) return;  // Re-entrancy guard
    mFiringCallbacks = true;
    while (mDeferredCallbackCount > 0) {
        mDeferredCallbackCount--;
        fireCallback();
    }
    mFiringCallbacks = false;
}

fireCallback() — One callback at a time:

cpp
void fireCallback() {
    if (mPendingTransmits > 0) mPendingTransmits--;
    if (mPendingTransmits == 0) mBusy = false;
    if (mCallback != nullptr) {
        using CallbackType = bool (*)(void*, const void*, void*);
        auto fn = reinterpret_cast<CallbackType>(mCallback);
        fn(nullptr, nullptr, mUserCtx);
    }
}

Time simulation:

cpp
u64 getMicroseconds() { return mSimulatedTimeUs; }
void delay(u32 ms) { mSimulatedTimeUs += static_cast<u64>(ms) * 1000; }

reset() — Full state reset:

cpp
void reset() {
    mInitialized = mEnabled = mBusy = false;
    mTransmitCount = 0;
    mConfig = FooConfig();
    mCallback = nullptr; mUserCtx = nullptr;
    mTransmitDelayUs = 0; mTransmitDelayForced = false; mShouldFailTransmit = false;
    mHistory.clear(); mPendingTransmits = 0;
    mSimulatedTimeUs = 0; mFiringCallbacks = false; mDeferredCallbackCount = 0;
}
Mock-Specific Test API (required)
cpp
void simulateTransmitComplete();           // Manually complete one pending transmit
void setTransmitFailure(bool should_fail); // Force transmit() to return false
void setTransmitDelay(u32 microseconds);   // Set forced delay
const fl::vector<TransmitRecord>& getTransmitHistory() const;
fl::span<const u16> getLastTransmitData() const;
size_t getTransmitCount() const;
bool isEnabled() const;
void clearTransmitHistory();
void reset();

Channel Driver

Implement IChannelDriver. State machine:

READY → (enqueue) → READY → (show) → BUSY → (poll) → DRAINING → (poll) → READY

Constructor pattern:

cpp
ChannelDriverFoo();                                          // Production
ChannelDriverFoo(fl::shared_ptr<IFooPeripheral> peripheral); // Testing

Chipset grouping: Channels with different timing (T0H, T1H, T0L, T1L) must be transmitted in separate groups. Sort by transmission time.

Tests

cpp
namespace {
void resetFooMockState() {
    auto& mock = FooPeripheralMock::instance();
    mock.reset();  // CRITICAL: reset between every test
}
}

FL_TEST_CASE("FooPeripheralMock - basic transmit") {
    resetFooMockState();
    auto& mock = FooPeripheralMock::instance();
    FooConfig config;
    config.num_lanes = 4;
    config.pclk_hz = 3200000;
    FL_REQUIRE(mock.initialize(config));
    u16* buffer = mock.allocateBuffer(1024);
    FL_REQUIRE(buffer != nullptr);
    FL_CHECK(mock.transmit(buffer, 1024));
    FL_CHECK(mock.waitDone(100));
    FL_CHECK(mock.getTransmitCount() == 1);
    mock.freeBuffer(buffer);
}

Driver Registration Priority

In channel_manager_esp32.cpp.hpp:

  • PARLIO: 4 (highest)
  • LCD_RGB: 3
  • RMT: 2
  • I2S: 1
  • SPI: 0
  • UART: -1

Buffer Alignment (64-byte for DMA)

cpp
u16* allocateBuffer(size_t size_bytes) {
    size_t aligned = ((size_bytes + 63) / 64) * 64;
#ifdef FL_IS_WIN
    return static_cast<u16*>(_aligned_malloc(aligned, 64));
#else
    return static_cast<u16*>(aligned_alloc(64, aligned));
#endif
}
void freeBuffer(u16* buffer) {
    if (!buffer) return;
#ifdef FL_IS_WIN
    _aligned_free(buffer);
#else
    fl::free(buffer);
#endif
}

Output Format (for reviews)

## Hardware Driver Review Results

### File-by-file Analysis
- **src/platforms/esp/32/drivers/spi/channel_engine_spi.cpp.hpp**: [findings]

### Findings by Category
- **DMA Safety**: N issues
- **Interrupt Safety**: N issues
- **Mock Rules**: N issues
- **Timing Constraints**: N issues

### Summary
- Files reviewed: N
- Violations found: N
- Violations fixed: N

Instructions

  • Focus on driver/platform code — skip application-level changes
  • Be thorough on DMA and interrupt safety (these cause hard-to-debug crashes)
  • Mock violations are P0 — async mocks with threads/wall-clock = flaky tests
  • Reference agents/docs/cpp-standards.md for general C++ rules
  • Make corrections directly when safe
  • Ask for user confirmation on significant changes

© FastLED, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/driver-review of FastLED/FastLED.

Open the folder on GitHubat commit ce225ed

Compare with similar skills

Driver Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Driver Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Driver Review this skillFastLED/FastLED7.5k—~3.1kAutomated safety check: PassMIT
Authoring VPhone Patch SetsLakr233/vphone-cli15k—~4.6kAutomated safety check: PassMIT
Sipeed I2C and SPI Hardware Controlsipeed/picoclaw30k—~578Automated safety check: PassMIT
RuView Hardware Setupruvnet/RuView97k—~1.8kAutomated safety check: NotesMIT
Esp32 Firmware Engineeralxv2016/folloup-sticky1161 repos~3.8kAutomated safety check: PassGPL-3.0
ExecuTorch Binary Size Reductionpytorch/executorch5.1k—~793Automated safety check: PassCustom licence

Similar skills

  • Authoring VPhone Patch Sets

    Lakr233/vphone-cli

    Explains how to declare a firmware patch in a vphone patch set, add a new set, or write a preset, including naming, gating and the checks that catch undeclared patches.

    15k GitHub stars~4.6k tokensUpdated today
    DevelopmentAuto-check passed
  • Reads and controls I2C and SPI peripherals on Sipeed boards such as LicheeRV Nano, MaixCAM and NanoKVM through the i2c and spi tools.

    30k GitHub stars~578 tokensUpdated 14 days ago
    DevelopmentAuto-check passed
  • Brings a RuView CSI sensing node online by building ESP32-S3 or ESP32-C6 firmware, flashing the board, provisioning WiFi and checking the serial output.

    97k GitHub stars~1.8k tokensUpdated today
    DevelopmentAuto-check: notes
  • Esp32 Firmware Engineer

    alxv2016/folloup-sticky

    ESP32 firmware engineering for ESP-IDF projects. An agent skill from alxv2016/folloup-sticky.

    116 GitHub starsUsed in 1 repo~3.8k tokens
    DevelopmentAuto-check passed
  • Measures and shrinks the ExecuTorch runtime binary by building a size test, analyzing it with bloaty and landing each reduction as its own pull request.

    5.1k GitHub stars~793 tokensUpdated today
    DevelopmentAuto-check passed
  • Sets up and runs 60 GHz and 24 GHz mmWave radar sensing on ESP32 boards in RuView, alone or fused with WiFi CSI.

    97k GitHub stars~907 tokensUpdated today
    DevelopmentAuto-check: notes

More from FastLED/FastLED

All 23 skills in this repo
  • CI Fix

    FastLED/FastLED

    Scan all CI builds and tests, find failures, fetch error logs, and fix the code.

    7.5k GitHub stars~897 tokensUpdated today
    Auto-check passed
  • Embedded Debug

    FastLED/FastLED

    Firmware crash analysis, stack trace decoder, and register dump interpreter for ESP32/ARM/AVR platforms.

    7.5k GitHub stars~1.4k tokensUpdated today
    Auto-check passed
  • Esp32 Log Triage

    FastLED/FastLED

    Parse and classify ESP32 serial log output to identify FastLED-related errors, RMT/I2S/SPI driver faults, timing violations, RTOS issues, and crash signatures.

    7.5k GitHub stars~1.9k tokensUpdated today
    Auto-check passed
  • Memory Audit

    FastLED/FastLED

    Audit embedded code for stack overflow risks, heap fragmentation, static allocation patterns, and memory leaks.

    7.5k GitHub stars~488 tokensUpdated today
    Auto-check passed
  • Platform Port

    FastLED/FastLED

    Guide porting FastLED to new MCU platforms, including int.h types, clockless drivers, SPI implementations, and platform detection.

    7.5k GitHub stars~580 tokensUpdated today
    Auto-check passed
  • TDD

    FastLED/FastLED

    Guide Test-Driven Development workflow for FastLED. An agent skill from FastLED/FastLED.

    7.5k GitHub stars~848 tokensUpdated today
    Auto-check passed

Categories

Questions about Driver Review

What does Driver Review do?

Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations. Driver Review is an agent skill from FastLED/FastLED. Review and implement hardware driver code — DMA safety, interrupt correctness, timing constraints, peripheral register usage, channel drivers, and peripheral mock implementations.

When should I use Driver Review?

Driver Review fits situations like: reviewing LED drivers; SPI/I2S/RMT/UART/PARLIO/LCDCAM peripherals; GPIO configuration; peripheral mock code.

How do I install Driver Review in Claude Code?

Run `npx skills add FastLED/FastLED --skill driver-review -a claude-code`. Or copy the skill folder (.claude/skills/driver-review in FastLED/FastLED) into .claude/skills/driver-review in your project. Claude Code loads it when a task matches its description.

How do I install Driver Review in Codex?

Run `npx skills add FastLED/FastLED --skill driver-review -a codex`. Or copy the skill folder (.claude/skills/driver-review in FastLED/FastLED) into .agents/skills/driver-review in your project. Codex loads it when a task matches its description.

Can I use Driver Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add FastLED/FastLED --skill driver-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/driver-review, .gemini/skills/driver-review, .github/skills/driver-review and .opencode/skills/driver-review in your project.

What does Driver Review need to run?

Going by SKILL.md and its folder, Driver Review needs the command-line tools its instructions call (git).

Does Driver Review access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Driver Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Driver Review use?

Driver Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Driver Review use?

About 3.1k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Driver Review?

Skills that share tags, products or a category with Driver Review: Authoring VPhone Patch Sets (Lakr233/vphone-cli, 15k stars), Sipeed I2C and SPI Hardware Control (sipeed/picoclaw, 30k stars), RuView Hardware Setup (ruvnet/RuView, 97k stars) and Esp32 Firmware Engineer (alxv2016/folloup-sticky, 116 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Driver Review?

FastLED (a GitHub organization) maintains it in FastLED/FastLED, which has 7,505 GitHub stars. The repository holds 23 skills in this directory. The repository was last updated on October 8, 2026.

Source: FastLED/FastLED on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.