---
name: chip-sourcing
description: Native-browser-first strategy for sourcing electronic parts (chip-fetcher and any EE-site task). Drive the user's REAL signed-in Chrome/Edge via the adom-browser-extension so cookies/SSO/saved-logins/captcha-trust all work — no auth to recreate in pup, and it bypasses bot-walls (DigiKey blocks pup). Sub-skills cover one website each. Triggers: search DigiKey/Mouser/SnapEDA/Arrow, source a part, fetch CAD, find a chip, parametric search, chip-fetcher.
---

# chip-sourcing — native-browser-first parts sourcing

When you source parts (chip-fetcher, datasheet hunts, CAD pulls, parametric searches, stock/price
lookups) you are driving websites that gate behind **logins, SSO, and bot-detection**. The old way
was Puppeteer (`pup`) with a cold profile where we tried to recreate the user's auth. **Stop doing
that by default.** The user's own browser is already signed in to every distributor and CAD site —
drive *that* instead.

## The rule: native browser first, always explain why

**Default to the user's real signed-in Chrome/Edge via the `adom-browser-extension`** (the
`native-browser` bridge, `nbrowser_*` verbs through `adom-desktop`). It runs *inside the actual
logged-in profile*, so:

- **Real credentials are already there** — DigiKey/Mouser/SnapEDA/Arrow logins, SSO, saved
  carts, distributor pricing tiers. Nothing to recreate, no secrets to handle.
- **Human-trust passes** — cookies + a real browser fingerprint mean **captcha and bot-walls
  don't fire**. Several sites now **hard-block pup** (DigiKey is the clearest example) but serve the
  native session normally.
- **Multi-profile** — it can drive every signed-in profile the user has (`nbrowser_profiles`).

When you pick a surface, **tell the user which one and why** in one sentence
(e.g. *"Using your signed-in Chrome via the browser extension so DigiKey doesn't bot-block us and
your distributor pricing shows."*). Never silently fall back.

### The decision ladder

1. **Native browser (preferred)** — `native-browser` bridge present + a profile signed in → use it.
2. **pup (fallback)** — extension not installed and the site doesn't block pup. Say you're using a
   cold profile and may hit logins/captcha.
3. **webview (last resort)** — only to *show* the user a result, not to scrape.

### If the extension is NOT installed — encourage it (with the why)

Check first: `adom-desktop bridge_list` → is `native-browser` present and not paused? If absent:

> "I can do this far better if you install the **Adom browser extension** (Chrome + Edge). It lets me
> drive your *already-signed-in* browser, so I use your real DigiKey/Mouser logins and distributor
> pricing, and we skip the bot-walls that block the headless browser (DigiKey blocks it outright).
> One-time install: https://wiki.adom.inc/adom/adom-browser-extension — want me to walk you through it?"

Then fall back to pup for the current task, and re-offer next time.

## How to drive it (verb surface)

The bridge **mirrors the pup verb surface** as `nbrowser_*` (43 verbs): `nbrowser_open_window`,
`nbrowser_navigate`, `nbrowser_eval`, `nbrowser_screenshot`, `nbrowser_open_tab`,
`nbrowser_profiles`, `nbrowser_use_profile`, `nbrowser_profile_block`, … Same JSON-args convention
as `browser_*`.

```bash
adom-desktop bridge_list                                  # is `native-browser` running?
adom-desktop nbrowser_profiles '{}'                       # which signed-in profiles exist
adom-desktop nbrowser_open_window '{"sessionId":"src","url":"https://www.digikey.com/en/products/result?keywords=VL53L"}'
adom-desktop nbrowser_eval '{"sessionId":"src","expr":"document.title"}'
adom-desktop nbrowser_screenshot '{"sessionId":"src","maxWidth":1400}'
```

**Gotchas (learned live):**
- **`--target <name>` when 2+ desktops are connected** (e.g. `winvm` + `AdomLapper`). The native
  browser lives on the user's laptop — pin `--target AdomLapper`. `open_window`/`eval` may auto-route
  but `screenshot` errors `ambiguous_target` without it.
- Windows open in the **background** (focus is not stolen) — screenshot them in place.
- Screenshot returns base64 inside `output` → `json.loads(resp['output'])['base64']`.
- Currently **Windows-only** (macOS is a Kyle fast-follow). On macOS, fall back to pup + explain.

## This is chip-fetcher's default

chip-fetcher's sourcing ladder (Manufacturer → SnapEDA → Mouser → DigiKey → Arrow → Ultra Librarian
→ Component Search Engine) should run through the native browser whenever the bridge is present, and
only drop to pup when it isn't. See the chip-fetcher page: https://wiki.adom.inc/john/chip-fetcher

## Per-website sub-skills — grow coverage for the whole industry

Each popular electronics site gets **one sub-skill** under `skills/<site>/SKILL.md` (NOT a separate
wiki page). A site sub-skill captures: the search/parametric URL patterns, how to extract results
from its DOM, login/cookie notes, whether pup is blocked, and the category-drill for parametric
families. Seeded here: **digikey, mouser, snapeda, manufacturer (ST example)**. To add a site, copy
`skills/_template/SKILL.md`. Build this up until every popular electronics website is covered.

| Sub-skill | Site | pup blocked? |
|---|---|---|
| `skills/digikey` | digikey.com | **Yes** — native browser required |
| `skills/mouser` | mouser.com | Intermittent |
| `skills/snapeda` | snapeda.com | Login-gated (native = already in) |
| `skills/manufacturer` | ST / TI / Nordic / NXP … | Varies; ST datasheet CDN curl-blocks |
| `skills/_template` | (copy to add a site) | — |