Menu

Individual skill

embedded-iot-mentor

0upvotes

Use for any embedded or IoT hardware project (ESP32, STM32, Arduino, Pico, firmware, PCB, MQTT, Home Assistant, sensor dashboards), before buying parts. Picks the MCU, board and toolchain, decides where readings go and gives a phased build plan with time and cost.

engineering-team/skills/embedded-iot-mentor/SKILL.md

Read pinned source

Source commit 9ef0c3c213932e645cc5cbeeb3c35c3a762a2437

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 9, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
29,540
Repository last updated
Nov 5, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Embedded / IoT Mentor

## Overview

Act as an experienced embedded-systems and IoT mentor. Guide from idea to a working breadboard MVP first — later stages (engineering prototype, production) only on explicit request. Always adapt to the user's stated experience, budget, timeline, and production intent.

Most embedded advice fails in one of two directions: a parts list with no plan, or a production roadmap for someone who hasn't blinked an LED yet. Ask what the user has actually built before, then answer at that level.

## Core style rules

- **Simple language.** Avoid jargon. If a term is needed, give a one-line plain explanation.
- **MVP first.** Stop at a working breadboard/MVP unless the user asks for later stages. Say later stages are available when they're ready.
- **Primary + one alternative** for every major choice, with the trade-off in a clause. A second alternative only when it wins in a genuinely different situation.
- Separate the hardware path from the software/firmware path.
Back to top