ci-fix

SkillMonitoring & ops

When your CI turns red, this skill lets your AI find out why and repair the code. It scans builds and tests, pulls the error logs from failing jobs, and applies fixes so you can get CI green again. It comes from the FastLED project's repository.

Available today. Use it from your connected AI after setup.

Add the skill, then when a build goes red ask your AI to check CI and repair it. It will scan the failures, read the logs, and fix the code.

Then ask your AI: use the ci-fix skill

What your AI can do with it

  • Scan all CI builds and tests to find failures
  • Fetch error logs from failing builds
  • Diagnose the cause of build and test failures
  • Fix failing code and tests
  • Work through failures in priority order: unit tests, then example tests, then uno, attiny85, esp32s3, esp32c6, and teensy41 builds

What this skill tells your AI

The instructions your AI receives, as published by fastled/fastled in .claude/skills/ci-fix/SKILL.md and read by ahel’s review.

Find and fix CI build and test failures across all platforms.

Arguments: $ARGUMENTS

Step 1: Scan builds and get error logs

Run the CI build scanner to discover all failing builds and tests with error context:

uv run ci/tools/gh/ci_builds.py --errors $ARGUMENTS

This auto-discovers workflows from .github/workflows/ matching build_*.yml, unit_test_*.yml, and example_test_*.yml. Adding a new workflow file automatically adds it to this report.

Step 2: Analyze and prioritize

Review the output. Builds are already sorted by priority:

  1. unit tests — unit_test_linux, unit_test_macos, unit_test_windows — fix first, these validate core logic
  2. example tests — example_test_linux, example_test_macos, example_test_windows — validate example compilation
  3. uno — AVR 8-bit, most constrained, most users
  4. attiny85 — AVR tiny, extreme flash/RAM constraints
  5. esp32s3 — ESP32-S3, primary ESP target
  6. esp32c6 — ESP32-C6, RISC-V ESP target
  7. teensy41 — Teensy 4.1, ARM Cortex-M7
  8. Everything else — alphabetical within non-priority builds

Fix priority builds first. If --board <name> was passed, focus only on those.

Step 3: For each failing test or build

For unit test failures:

  1. Read the error logs from the scan output
  2. Run the failing test(s) locally: bash test or bash test <TestName>
  3. If a test fails, re-run in debug mode: bash test <TestName> --debug
  4. Identify the root cause and fix the source code or test
  5. Verify: bash test

For example test failures:

  1. Read the error logs from the scan output
  2. Run the failing example(s) locally: bash compile wasm --examples <ExampleName>
  3. Identify the root cause (missing include, type error, API change, etc.)
  4. Fix the source or example code
  5. Verify: bash compile wasm --examples <ExampleName>

For board build failures:

  1. Read the error logs from the scan output
  2. Identify the root cause (missing header, type error, platform ifdef, linker error, etc.)
  3. Find the relevant source file(s) and read them
  4. Make the fix — prefer the simplest change that fixes the error:
    • Missing platform guard → add #ifdef / #if defined()
    • Missing include → add the include
    • Type mismatch → fix the type
    • API difference → use conditional compilation
  5. After fixing, verify by compiling: bash compile <board> --examples Blink (use the board arg from the scan output, e.g. bash compile uno --examples Blink)

Step 4: Verify fixes don't break other platforms

After fixing a failing build, consider whether the change could break other platforms. If you changed shared code (not platform-guarded), spot-check by compiling another platform:

bash compile wasm --examples Blink

Notes

  • The scanner discovers workflows dynamically — no hardcoded list to maintain
  • Workflow patterns: build_*.yml, unit_test_*.yml, example_test_*.yml
  • Use --board uno,esp32s3 to focus on specific boards
  • Use --all flag if you want to see passing builds too (default: only failing with --errors)
  • Error logs show up to 5 error blocks per build with surrounding context
  • The priority list is defined in ci/tools/gh/ci_builds.py in the PRIORITY_BOARDS constant

Signals

GitHub stars
7k
Forks
2k
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
ci-fix
Source
github.com/fastled/fastled