← Commit history

Delete skills/hd-eda-discovery/SKILL.md

John Lauer ·6bc9ea777f ·2mo ago ·parent c2331b1
1 file changed −107
skills/hd-eda-discovery/SKILL.mddeleted−107
@@ -1,107 +0,0 @@-----name: hd-eda-discovery-description: >-  The onboarding playbook a (second, background) Claude conversation runs after HD setup to-  discover which EDA / electronics-design tools the user runs — KiCad, Fusion 360, Altium,-  OrCAD/Cadence — and onboard them into the AI-first electronics workflow. If KiCad/Fusion-  (we have bridges): remember their preferred tool in a prefs file, offer to open example-  files, and pitch the gerber-export → order-at-JLCPCB/PCBWay/OSHPark loop. If Altium/OrCAD-  (no bridge yet): pitch co-building a bridge with the AI and publishing it to the Adom wiki-  for the community (KiCad/Fusion bridges are the reference). READ + RUN this when a new-  thread is asked to "explore what EDA software I use" / on the post-setup discovery pass.-  Trigger words — eda discovery, what eda software, what cad do i use, electronics design-  tools, detect kicad, detect fusion, detect altium, detect orcad, onboard eda, pcb workflow,-  order pcb, gerbers, jlcpcb, pcbway, oshpark, write a bridge, altium bridge, orcad bridge,-  publish to adom wiki, ai-first electronics, who am i and what can i do, post-setup explore.------# EDA tool discovery & onboarding (guidance for the per-tool setup threads)--> **How this runs now (2026-07-16):** the setup cascade no longer runs a single combined-> "discovery" conversation. It opens **dedicated per-tool AI-thread steps** —-> `thread-kicad`, `thread-fusion360`, `thread-altium` (plus `thread-parts-search`,-> `thread-chip-fetcher`, etc.). This skill is the **detection + onboarding playbook those-> threads use**: how to detect each EDA tool, the opt-in philosophy, and what to offer.--When you're one of those EDA threads (or a user asks "what EDA software do I use / what can you-do with it"), be **exploratory and opt-in** — detect first, then offer; never auto-install or-auto-build. Detect quietly, then come back with a short, friendly summary + one clear offer.--## 1. Detect (via `adom-desktop` — see `hd-adom-desktop`, `hd-bridges`, `pup`)--```bash-adom-desktop status                       # relay up? caps include kicad / fusion360?-adom-desktop kicad_list_versions '{}'     # KiCad installed (+ which versions)-adom-desktop fusion_status '{}'           # Fusion 360 installed? ("installed but not running" = yes)-# No bridge for these — detect by install path / running process:-adom-desktop run_script '{"interpreter":"powershell","scriptB64":"<b64 of:>"}'-#   Get-ChildItem 'C:\Program Files','C:\Program Files (x86)' -Directory -EA 0 |-#     ? { $_.Name -match 'Altium|OrCAD|Cadence|Allegro|EAGLE|DipTrace|Eplan' } | % Name-#   plus: Get-Process | ? { $_.Name -match 'Altium|OrCAD|Capture|Allegro' } | % Name-```-(Base64 the PowerShell for `run_script`; use absolute paths, and treat **empty output as a-timeout**, not a negative result.)--## 2. Branch on what you found--### A) KiCad and/or Fusion 360 found — we have bridges, go deep (opt-in)-1. **Remember it.** Write a small prefs file so future threads skip re-detection:-   ```bash-   mkdir -p ~/.adom-   cat > ~/.adom/eda-prefs.json <<'JSON'-   {"primary":"kicad","versions":["10.0"],"fusion":true,"detectedAt":"<date>",-    "notes":"user runs KiCad v10; Fusion installed (read-only/expired)"}-   JSON-   ```-   (Also worth a one-line memory note if you keep memories.)-2. **Show, don't tell** — offer to open an example so they *see* it work:-   *"Want me to open a sample board in KiCad and pop the 3D viewer so you can see what I can drive?"* → use the `pic_programmer` demo flow (`hd-self-screenshot`/`adom-desktop-kicad`): open `.kicad_sch` + `.kicad_pcb`, symbol/footprint editors, then the **board** 3D viewer (close the footprint+symbol editors first — `kicad_open_3d_viewer` attaches to the active editor otherwise).-3. **Pitch the loop** that AI makes effortless — *"From here I can export gerbers and help you-   order the board — JLCPCB, PCBWay, or OSHPark."* If they're keen, that's the on-ramp to (4).-4. **The real unlock — build the glue, publish it.** Most fab vendors have no clean API, so the-   value is AI-built automation: *pull from KiCad → stage in the workspace → drive the-   vendor's upload flow (pup) → order.* Offer to **vibe-code an uploader/automation app** for-   their fab of choice and **publish it to the Adom wiki** so the whole community gets it. This-   is exactly what the wiki is for (see §3).--### B) Altium / OrCAD / Allegro / EAGLE / other — no bridge yet (the community pitch)-We don't have a bridge for these — **but that's an opportunity, not a dead end.** Offer:--> *"You're on **Altium** — we don't have an Adom bridge for it yet, but we have a wiki for-> sharing apps with the whole community, and we could **build one together right now**. The-> KiCad and Fusion 360 bridges are great references for the AI to model the design on — it's-> probably ~30 minutes of vibe-coding. Then we publish it to the Adom wiki so every Altium-> user gets it. We could all use it. Want to?"*--- Reference bridges: `adom-inc/adom-desktop/plugins/kicad/` and `…/plugins/fusion360/` (a Python-  bridge that the desktop app dispatches to; see `adom-desktop-kicad`/`-fusion` for the verb-  shape). A new bridge = the same pattern (launch app, open files, screenshot, send keys, an-  optional in-process add-in for the richer API).-- Publish flow: the Adom wiki hosts shared apps (`apps/<name>`) — see the wiki publish skills.--### C) Nothing detected / unsure-Ask what they design boards in, and whether they'd like a bridge or workflow built. Keep it-one friendly question, not an interrogation.--## 3. The frame (why this matters — say it briefly, don't lecture)-The electronics industry is moving **AI-first**, and the tools mostly aren't built for it yet.-**Adom is where that comes together:** you build an AI-first app (a bridge, an uploader, a-fab-automation glue), publish it to the **Adom wiki**, and the whole community can install and-improve it. KiCad/Fusion bridges, a JLCPCB/PCBWay/OSHPark uploader, an Altium bridge — each one-makes the next person's AI-first workflow turnkey. The user isn't just configuring their setup;-they can **contribute the missing piece** in half an hour.--## 4. Etiquette-- **Opt-in always.** Detect silently; *offer* the demo/build — don't open apps or write code-  unprompted. One clear offer beats five questions.-- **Don't overpromise vendor APIs.** JLCPCB/PCBWay/OSHPark uploads are mostly UI automation-  (pup), not clean APIs — frame the uploader as AI-driven glue, and verify pages exist before-  templating URLs (`pup` skill).-- **Respect read-only states** (e.g. an expired Fusion subscription is view/query-only).-- Report back to the user concisely: *what you found, one thing you can show them now, and one-  thing worth building.*--## Related skills-- [hd-adom-desktop](../hd-adom-desktop/SKILL.md) / [hd-bridges](../hd-bridges/SKILL.md) — the `adom-desktop` relay + KiCad/Fusion bridge verbs (in-distro names; the `adom-desktop-*` skills are the cloud-side equivalents)-- `pup` — driving fab-vendor upload pages; [hd-open-url](../hd-open-url/SKILL.md) — opening vendor sites-- the Adom wiki publish skills — sharing the bridge/app you build with the community