From mcu-go
Guide MCU hardware interface feasibility analysis and hardware connection file writing. Use when Codex needs to confirm a release requirements document, locate the target STM32 MCU model, fetch the matching STMicroelectronics STM32_open_pin_data XML under docs/mcu, collect module manuals organized under docs/modules/module-name folders with PDFs and images, convert supplemental PDF module/manual sources to Markdown, extract image-confirmed exposed module pins, analyze module and MCU peripheral sufficiency, and write docs/releases/VERSION/hardware.json when the design is feasible.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mcu-go:hardware-interface-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill to turn a requirement document, ST MCU XML pin data, and module manuals into a feasibility decision and a hardware connection file.
Use this skill to turn a requirement document, ST MCU XML pin data, and module manuals into a feasibility decision and a hardware connection file.
Use the single-project release layout:
docs/releases/<version>/
requirements.md
hardware.json
software_design.md
cubemx_build.md
notes.md
If the user names a release version, use that version exactly after sanitizing it to a directory-safe name such as v1.0. If the user does not name a version, use the newest semantic version under docs/releases. If no release exists, create docs/releases/v0.1.
docs/releases/<version>/requirements.md. If the user has not identified a release and multiple releases exist, choose the newest semantic version unless the user asks for another one.requirements.md or the user's input, for example STM32F103C8T6. The model must be specific enough to determine package, memory/capacity, and ordering suffix.scripts\fetch_stm32_pin_xml.py first. It matches the complete STM32 ordering code against a built-in list of official STM32_open_pin_data/mcu XML filenames, downloads the unique match to docs\mcu\, and writes a sibling .source.json trace file. If it returns candidates instead of downloading, rerun it with a more specific ordering code..source.json path in the report and in project notes when notes are being updated.docs\modules\<module-name> for modules that implement required functions. Each module folder may contain PDFs and images. Do not require manuals for basic parts such as buttons, LEDs, simple resistors, or generic pull-ups unless the user asks for them.requirements.md or the user request, such as STM32F103C8T6.python ".\skills\hardware-interface-writer\scripts\fetch_stm32_pin_xml.py" STM32F103C8T6 --output-dir ".\docs\mcu"
x characters as single-character wildcards and grouped fields such as (8-B) or (C-E) as ordering-code character ranges. For STM32F103C8T6, the expected unique match is STM32F103C(8-B)Tx.xml.--force is supplied. Use --dry-run to verify matching without writing files, and --json when another tool needs structured output.docs\mcu\<xml-file>.source.json path in the output report and any release notes you update.Ask for module manuals for non-basic modules needed by the requirement. Prefer docs\modules\<module-name>\ folders containing all related PDFs and images. Keep a short intake table with module name, required function, provided files, and status. Legacy flat folders such as docs\modules\pdf, docs\modules\image, and docs\modules\markdown may exist, but prefer the module-folder layout when both are present.
Perform a shallow sufficiency check before conversion:
likely sufficient only if its name or visible metadata clearly matches the required function.unclear when the interface, voltage, range, channel count, or protocol cannot be confirmed yet.insufficient when the visible information already conflicts with the requirement.Convert supplemental PDFs to Markdown with the bundled script. This is required for module manuals provided as PDFs and optional for supplemental MCU datasheets/pinout PDFs; it does not replace the ST XML default source. Do not call or depend on any external PDF-conversion skill. In the preferred module layout, the script writes docs\modules\<module-name>\manual.md, textifies PDFs first, and appends image-review placeholders.
The script requires PyMuPDF. Install it once before first use:
pip install pymupdf
python "<skill_dir>\scripts\pdf_to_md.py" --modules-dir ".\docs\modules"
If the user provides a supplemental MCU PDF, convert it to Markdown as supporting evidence only:
python "<skill_dir>\scripts\pdf_to_md.py" ".\docs\mcu\supplemental_pinout.pdf" --output-dir ".\docs\mcu\markdown"
For a specific module folder:
python "<skill_dir>\scripts\pdf_to_md.py" ".\docs\modules\INA219"
For legacy flat PDF folders only:
python "<skill_dir>\scripts\pdf_to_md.py" --source-dir ".\docs\modules\pdf" --output-dir ".\docs\modules\markdown"
manual.md and fill the image-review placeholder with only image-confirmed hardware facts: exposed module pins, terminal labels, connector direction, voltage labels, jumper/solder-pad settings, and special wiring notes. If a PDF chip manual and a module image disagree, use the image-confirmed module-exposed pins in the connection file. Mark anything unreadable or not visible as unclear; do not guess or substitute bare IC pins for module connector pins.docs\mcu\*.xml plus the converted module manuals:
references/hardware_interface_spec.md and write the hardware connection file in that schema. Use the fixed output path docs\releases\<version>\hardware.json. Create docs\releases\<version> when it does not exist. Inspect any existing hardware.json before overwriting it.When reporting results, include:
likely sufficient, unclear, or insufficient.manual.md files and any image-confirmed exposed pin overrides.feasible, feasible with assumptions, or not feasible.Before writing the connection JSON, load references/hardware_interface_spec.md.
Use these additional rules:
devices before using it in connections or power_connections.docs\modules\<module-name>, use the exact folder name <module-name> as the device name in devices, connections, and power_connections. Do not rename it with extra descriptive suffixes or marketing labels.notes, such as pull-up resistors, voltage dividers, level shifters, boot-pin cautions, or shared-bus address constraints.notes.<MCU设备名>:3V3_OUT and <MCU设备名>:5V_OUT as ordinary pins when the board exposes them. If such a power output is used, include it in both connections and power_connections.Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
npx claudepluginhub aregues/mcu-go --plugin mcu-go