supported-devices - sync the boards list with what just landed
SkillAI & modelsThe user invokes `/supported-devices` after board work landed - either a whole new board bring-up or a single feature on an existing board. It syncs `launcher/supported_devices.py` with reality (append the board entry / flip `supported` / flip the feature keys the agent actually worked on), then runs `./compile_readme.py` to regenerate `README.md`. Invoke when the user types `/supported-devices` or asks to update the supported boards list.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the supported-devices - sync the boards list with what just landed skill
What this skill tells your AI
The instructions your AI receives, as published by gweslab/cerf in .claude/skills/supported-devices/SKILL.md and read by ahel’s review.
The user invoked /supported-devices. Update launcher/supported_devices.py to match the board work done this session, then regenerate the README.
User-invoked only. Only the user triggers this skill by typing /supported-devices. An agent never invokes it on its own initiative - landing board work is not a license to edit the boards list.
Procedure
-
Open
launcher/supported_devices.pyand read its docstring +FEATURE_SPECS+ a neighboring board entry - the file documents its own semantics; follow them, not memory. -
Whole-board bring-up: append the board's dict to
BOARDS_INFORMATIONif absent (match an existing entry's shape:name,board_idexactly as cerf'sBoardContextreports it,socconstant,operating_systemslist of the OSes the board actually boots in this cerf version,features), and setsupported: Trueif the board is now user-ready (False= early WIP, hidden by default). -
Feature work (also part of case 2 above): sync the
featuresdict to reality. Tri-state, apply it exactly:True- hardware present AND working in CERFFalse- hardware present on the real board but unsupported in CERF- key absent - the board has no such hardware (never write
Falsefor hardware that doesn't exist)
Only recognised keys from
FEATURE_SPECSare valid. NewSoc/OperatingSystemconstants follow the existing ones at the top of the file. -
Run
python compile_readme.py(from repo root) to regenerateREADME.md. Confirm it printsREADME.md compiled (vX.Y).
What to flip - and what not to
- Flip only what you know. You worked on the board/feature, so you know which features you brought up, which exist but stay unsupported, and which the hardware simply lacks. Do not guess states for features you didn't touch and can't verify - leave them as they are.
notesstay blank. Never write or propose notes from this skill - a new board entry carries nonoteskey, and existing entries' notes are left untouched.
Git
Do not run any git command unless the user explicitly asks (e.g. "stage your changes", "commit"). When they do, launcher/supported_devices.py and the regenerated README.md are both part of the changeset - include both.
Signals
- GitHub stars
- 91
- Forks
- 9
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
supported-devices- Source
- github.com/gweslab/cerf