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.
curl -O https://raw.githubusercontent.com/SensorsIot/Embedded-AI-Harness/main/.claude/skills/setup-action/SKILL.mdgit clone --depth 1 https://github.com/SensorsIot/Embedded-AI-HarnessWrote 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.
[](https://agentmods.dev/skills/sensorsiot/embedded-ai-harness/setup-action)<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>- NVIDIA SkillSpector warn
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.
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.
| Model | Per session | Once 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 |
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.
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 }}
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.
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.
- 9d ago First seen · 493 lines · 0 tokens per session scan A 6f4e38e7960a
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.
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…
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…
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…
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…
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…
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…