Skip to main content
Jeden Skill in Manus ausführen
mit einem Klick
GitHub-Repository

vibe-hardware

vibe-hardware enthält 4 gesammelte Skills von luckiday, mit Repository-Berufsabdeckung und Skill-Detailseiten auf SkillsMP.

gesammelte Skills
4
Stars
3
aktualisiert
2026-07-13
Forks
0
Berufsabdeckung
4 Berufskategorien · 100% klassifiziert
Repository-Explorer

Skills in diesem Repository

vibe-cad
Maschinenbauingenieure

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, FITTING a board + modules into a housing, SWAPPING the module/sensor a shell wraps, or RESIZING to seat an off-the-shelf part. Key facts this skill encodes: the model is one PARAMETRIC python file (a param block = single source of truth + importable `build_*()` builders, no side effects); review is the **CAD Viewer**, which has NO CAD kernel — it renders `.step` only via a hidden GLB sidecar `.<name>.step.glb`, so `build_all.py` must `export_gltf` each part; the viewer is vendored by `npx skills install earthtojake/text-to-cad` and is launched/updated via `scripts/cad_viewer.sh` (which works around the fixed-port + renamed-launcher gotchas). Worked reference: a device shell under `examples/`. Upstre

2026-07-13
vibe-pcb
Elektronikingenieure (außer Computer)

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 map. Key facts this skill encodes: the KiCad project is GENERATED BY SCRIPT — you edit `gen_sch.py` / `gen_pcb.py`, never the `.kicad_*` files; geometry is COMPUTED by `scripts/pcblib/` (relations in, coordinates out: contracts feed the outline and connector positions, `beside/align_pads/at_edge/Cluster` place parts off real courtyards, numeric gates fail bad floorplans before copper, `placement.json` is exported as evidence); every net lives ONCE in `parts.yaml` (schematic and copper both derive from it); validation is ERC/DRC driven to 0 ERROR-severity + 0 unconnected (silk WARNINGS are cosmetic, don't conflate) with launchers that degrade honestly on kicad-cli < 8; fab is `scripts/fab_export.s

2026-07-13
vibe-plm
Industrieingenieure

The integration / product-lifecycle layer ABOVE vibe-firmware · vibe-pcb · vibe-cad: turn a small embedded product into a single PRODUCT MANIFEST plus the INTERFACE CONTRACTS the three domains must agree on, keep them in sync across a revision, and gate a release/fab on all three being green at once. Use when STARTING a new product (scaffold the firmware/pcb/cad dirs + manifest), CHANGING something that crosses a domain boundary (a pin move, a board-outline change, a shared fit number), CUTTING a revision, or wiring up a fab/release. Key facts this skill encodes: the product is one `product.yaml` — identity + per-domain status + the interface contracts — and it is the single source of truth (the architecture's "fit numbers + net map" box made concrete); there are exactly three contracts — `pinmap.yaml` (pcb -> firmware), `board.step` (pcb -> cad, a GENERATED artifact), `constraints.yaml` (cad <-> pcb, the shared fit numbers) — direction is producer -> consumer; `revision` (vYYYY-MM-DD) bumps on ANY cross-doma

2026-07-13
vibe-firmware
Softwareentwickler

Take embedded firmware for a small device (ESP32 / RP2040 / STM32 / nRF …) from a plain-language spec to a reproducible build that flashes and runs, driven by an AI coding agent. Use when bringing up a new board, adding a peripheral/driver, wiring a device to a network service, or shipping an update. Key facts this skill encodes: structure the firmware as LAYERED COMPONENTS, not one big main.c — a board-support layer (BSP) is the ONLY place pin numbers + low-level init live and exposes a typed API (i2c bus, PMIC/battery, buttons) so nothing else touches a raw GPIO; ONE COMPONENT PER DOMAIN (display/ui, audio, connectivity…) each with a single public header as its only surface; and a THIN main that wires them via callbacks + a FreeRTOS event queue + a small state machine. Build in a PINNED toolchain (a Docker image / locked SDK) so it's bit-for-bit reproducible; keep board/pin config as CODE (the BSP header) mirroring the PCB net map; ship dual-slot OTA from day one and NEVER publish an update without a real-h

2026-06-22