Embedded-AI-Harness: Skill for Claude Code

.claude/skills/setup-action/SKILL.md

setup-action is a skill for Claude Code from SensorsIot/Embedded-AI-Harness. It costs 185 tokens per session (5,412 once invoked), scanned A, original, MIT.

A guide for setting up GitHub Actions, GitHub's automated build and test service, for ESP32 firmware projects. It defines separate workflows for checking changes and building or publishing firmware.

In plain words
What is it for?
Use it to build ESP-IDF firmware in a fixed container, take versions from Git tags, verify published images, publish build files and releases, and run lint and tests on pushes and pull requests.
Why use it?
It makes firmware builds repeatable and records whether a change passes the pre-merge checks, while keeping hardware testing as a separate step.

Skill for Claude Code

Written for Claude Code: installed under .claude/. Also seen: positional $N argument.

This is SensorsIot/Embedded-AI-Harness's own configuration. It tells Claude Code how to work on Embedded-AI-Harness itself, so it is not a mod to install elsewhere. Copy it as a starting point and replace the rules that are about this project. Everything Embedded-AI-Harness configures →

Reuse

Borrowing it

Nothing to install: this file belongs to SensorsIot/Embedded-AI-Harness. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file
curl -O https://raw.githubusercontent.com/SensorsIot/Embedded-AI-Harness/main/.claude/skills/setup-action/SKILL.md
Clone the repo
git clone --depth 1 https://github.com/SensorsIot/Embedded-AI-Harness

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for setup-action

README.md
[![agentmods](https://agentmods.dev/badge/skills/sensorsiot/embedded-ai-harness/setup-action.svg)](https://agentmods.dev/skills/sensorsiot/embedded-ai-harness/setup-action)
Your own site
<a href="https://agentmods.dev/skills/sensorsiot/embedded-ai-harness/setup-action"><img src="https://agentmods.dev/badge/skills/sensorsiot/embedded-ai-harness/setup-action.svg" alt="Measured on agentmods" height="20"></a>
Per session 185 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 5,412 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe. Third-party audits
  • NVIDIA SkillSpector warn 7 Sept 2026
SkillSpector: 1 finding, up to medium

These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →

  • medium Output Handling · line 339
    Output size or generation rate is not bounded. Unbounded output enables denial-of-service through resource exhaustion, log flooding, or context-window stuffing.
    Fix: Set explicit limits on output length, generation count, and rate. Use max_tokens and truncation to prevent unbounded output.
How audits are shown
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00185 $0.05412
Opus 5 $0.00093 $0.02706
Sonnet 5 $0.00037 $0.01082
Haiku 4.5 $0.00018 $0.00541

Measured 9d ago against content hash 6f4e38e7960a, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-08, from the pricing page.

Security

Grade A, and why

setup-action scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/setup-action/SKILL.md · 493 lines

How it starts

The opening of the file, as written. The whole thing — 493 lines — stays where its author put it; the contents beside it link to each section on GitHub.

CI for ESP32 projects

Two workflows with different jobs, and most projects want both:

Workflow Trigger Answers
build every push; publishes on a version tag Can this be flashed, and where is the artefact?
gate every push and PR May this change land?

The build workflow is the substantial one and comes first below. The gate is simpler but has a rule that decides whether it is worth having at all: a gate must be green from its first run, or it teaches everyone to ignore a red tick.

Neither replaces hardware testing. A green tick means it compiles and the pure logic passes.


Part 1 — Build and publish firmware

Put this at .github/workflows/build.yml and fill in <firmware-dir>, <app-name> and <target>. Drop working-directory if the ESP-IDF project sits at the repository root.

One build per run. Most projects have one firmware, and the template defaults to that: MULTI_VARIANT: 'false' pins every run to production, and <marker> and <alt-variant> are then never read. Flip it to 'true' only for a project that genuinely ships a second image, and read "Variants" below before you do.

name: Build Firmware

env:
  IDF_TAG: v6.0.2          # keep in step with the container tag below
  # The one switch for variant handling. Leave 'false' unless this project
  # really builds a second image; then set <marker> too.
  MULTI_VARIANT: 'false'
  VARIANT_MARKER: <marker>  # a string only the non-production image contains

on:
  push:
    branches: [main]
    tags: ['v*.*.*']
  workflow_dispatch:
    inputs:
      version:
        description: 'Version number (e.g. 1.2.0)'
        required: true
      variant:                       # inert while MULTI_VARIANT is 'false'
        description: 'Which firmware to build'
        type: choice
        options: [production, <alt-variant>]
        default: production

permissions:
  contents: write          # required to create the release

jobs:
  build:
    runs-on: ubuntu-latest
    container: espressif/idf:v6.0.2
    defaults:
      run:
        working-directory: <firmware-dir>
        shell: bash

    steps:
      # Must come first, and must not be skipped. The container runs as root
      # while the workspace belongs to the runner user, so every git call in a
      # `run:` step dies with "detected dubious ownership" — see "The container
      # runs as the wrong user" below.
      - name: Trust the workspace
        working-directory: ${{ github.workspace }}
        run: git config --global --add safe.directory '*'

      - uses: actions/checkout@v4
        with:
          fetch-depth: 0     # see "Versioning" below — tags are needed

      - name: Show the IDF version actually used
        run: . $IDF_PATH/export.sh >/dev/null && idf.py --version

      - name: Decide what to build
        id: plan
        run: |
          VARIANT="${{ github.event.inputs.variant || 'production' }}"
          [ "$MULTI_VARIANT" = "true" ] || VARIANT=production

          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
            VERSION="${{ github.event.inputs.version }}"
          elif [[ "$GITHUB_REF" == refs/tags/v* ]]; then
            VERSION=${GITHUB_REF#refs/tags/v}
          else
            VERSION="0.0.0-$(git rev-parse --short HEAD)"
          fi

          DEFAULTS="sdkconfig.defaults"
          if [ "$VARIANT" != "production" ]; then
            DEFAULTS="sdkconfig.defaults;sdkconfig.$VARIANT.defaults"
            VERSION="$VERSION-$VARIANT"
          fi

          { echo "variant=$VARIANT"; echo "version=$VERSION"
            echo "defaults=$DEFAULTS"; } >> $GITHUB_OUTPUT
          echo "Building the $VARIANT firmware as $VERSION"

      # -DSDKCONFIG: keep the config in the build dir — see "sdkconfig" below.
      - name: Build firmware
        run: |
          . $IDF_PATH/export.sh >/dev/null
          ARGS="-B build -DSDKCONFIG=$PWD/build/sdkconfig \
                -DSDKCONFIG_DEFAULTS=${{ steps.plan.outputs.defaults }} \
                -DPROJECT_VER=${{ steps.plan.outputs.version }}"
          idf.py $ARGS set-target <target>
          idf.py $ARGS build

      - name: Verify the image matches the variant asked for
        if: env.MULTI_VARIANT == 'true'
        run: |
          grep -q "$VARIANT_MARKER" build/<app-name>.bin && FOUND=yes || FOUND=no
          WANT=no; [ "${{ steps.plan.outputs.variant }}" = "production" ] || WANT=yes
          if [ "$FOUND" != "$WANT" ]; then
            echo "FATAL: ${{ steps.plan.outputs.variant }} image, marker found=$FOUND, expected=$WANT"
            exit 1
          fi
          echo "verified: ${{ steps.plan.outputs.variant }} image, marker $FOUND"

      - name: Collect artefacts
        run: |
          V="${{ steps.plan.outputs.version }}"
          cp build/<app-name>.bin firmware_v${V}.bin
          cp build/<app-name>.elf firmware_v${V}.elf
          # Cold-flash set, taken from flash_args rather than named here —
          # see "Never hand-write the image list" below.
          mkdir -p coldflash
          cp build/flash_args coldflash/
          awk '$1 ~ /^0x/ {print $2}' build/flash_args | while read -r f; do
            cp "build/$f" coldflash/ || { echo "FATAL: missing build/$f"; exit 1; }
          done
          cp build/sdkconfig sdkconfig.generated

      - uses: actions/upload-artifact@v4
        with:
          name: firmware-v${{ steps.plan.outputs.version }}
          path: |
            <firmware-dir>/firmware_v*.bin
            <firmware-dir>/firmware_v*.elf
            <firmware-dir>/sdkconfig.generated
            <firmware-dir>/coldflash/*.bin

      - uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            <firmware-dir>/firmware_v*.bin
            <firmware-dir>/firmware_v*.elf
          generate_release_notes: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Read the full file on GitHub · 493 lines

Files

What ships with it

1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 9d ago First seen · 493 lines · 0 tokens per session scan A 6f4e38e7960a

Subscribe to this mod's changes

setup-action is a skill published in the GitHub repository SensorsIot/Embedded-AI-Harness (173 stars, last pushed 28d ago), licensed MIT. It adds 185 tokens to every session and 5,412 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

m5stack-cap-lora-1262

Hardware reference and firmware helper for the M5Stack Cap LoRa-1262 (SKU U214) — a snap-on cap for the Cardputer Adv (K132-Adv) and CardputerZero that carries a Semtech SX1262 sub-GHz LoRa radio (868–923 MHz, +22 dBm TX, external RP-SMA antenna) and an ATGM336H-6N GNSS receiver (GPS/QZSS/BeiDou/Galileo/GLONASS, UART…

iot-forge/m5stack-skills · 254 tokens

new-device-skill

Build or update an M5Stack hardware skill in this marketplace — a Controller (a board that runs firmware, like Core2 or AtomS3), a Unit (a peripheral you drive from a Controller, like a ToF sensor or a relay), or a Chip (an Espressif SoC capability layer, like esp32-c6). Use whenever adding a new board/unit/chip to…

iot-forge/m5stack-skills · 171 tokens

m5stack-tab5

Hardware reference and development helper for the M5Stack Tab5 (product code C145) — an ESP32-P4-based 5" touchscreen IoT/industrial terminal with an ESP32-C6 wireless co-processor, MIPI-DSI display, MIPI-CSI camera, ES8388 audio codec, BMI270 IMU, RX8130CE RTC, RS485, and a removable NP-F550 battery. Use this skill…

iot-forge/m5stack-skills · 236 tokens

m5stack-core2

Hardware reference and development helper for the M5Stack Core2 family — a 2.0" touchscreen ESP32 (classic, Xtensa LX6) Controller built around an AXP192 power management IC, ILI9342C display, FT6336U capacitive touch, BM8563 RTC, and (on original/1.1/1.3 revisions) an MPU6886 or BMI270 IMU. Covers the plain Core2…

iot-forge/m5stack-skills · 328 tokens

esp32-c6

Chip-level ESP-IDF capability reference for the ESP32-C6 SoC (single-core RISC-V HP core + RISC-V LP core, WiFi 6 + BLE 5.3 + Thread/Zigbee) — what the chip can do, distinct from any board's wiring. Use when a user wants to exploit ESP32-C6 hardware — WiFi 6/BLE/802.15.4 radio coexistence (Thread Border Router, Zigbee…

iot-forge/m5stack-skills · 307 tokens

esp32

Chip-level ESP-IDF capability reference for the classic ESP32 SoC (dual-core Xtensa LX6) — what the chip can do, distinct from board wiring. Covers the ESP32-D0WDQ6-V3 / ESP32-D0WD-V3 / ESP32-D0WDR2-V3 die family used in ESP32-WROOM-32 and ESP32-WROVER modules. Use for RMT (IR/WS2812), LEDC (PWM), I2S (audio/parallel…

iot-forge/m5stack-skills · 306 tokens