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

---
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