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 0 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/github.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/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for setup-action

Your own site · 80×15
<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="Reviewed on agentmods" width="80" height="20"></a>
Per session 0 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.00000 $0.05412
Opus 5.5 $0.00000 $0.02165
Sonnet 5.5 $0.00000 $0.01082
Haiku 4.5 $0.00000 $0.00541

Measured 2mo ago against content hash 6f4e38e7960a, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, 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 2mo 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. 2mo 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 (273 stars, last pushed 20d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 5,412 tokens. 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

vibe-industrial-design

Take a product's OUTER APPEARANCE (industrial design: form, proportion, panel split, CMF, controls layout) from a brief + AI-generated look images to a parametric three.js appearance model, a fixed-camera contact sheet, Blender Cycles finals, and a versioned ID report (md authority + Word snapshot) — driven by an AI…

luckiday/vibe-hardware · 580 tokens

vibe-pcb

Take a small PCB from a natural-language spec to an ERC/DRC-clean, review-grade KiCad design and a fab order — written for a PCB beginner driving KiCad via Claude Code. Use when designing a NEW dev board / module-carrier PCB, SWAPPING the module or sensor on an existing carrier, or CHANGING the layout / outline / net…

luckiday/vibe-hardware · 409 tokens

vibe-cad

Take a mechanical part / enclosure from a natural-language spec to a parametric build123d model, reviewed interactively in the latest CAD Viewer and exported as STEP/STL for print or tooling — written for a beginner driving CAD via Claude Code. Use when designing or revising an ENCLOSURE / bracket / carrier-shell…

luckiday/vibe-hardware · 273 tokens