skill

chip-sourcing-skillpack

Public Unreviewed

by John Lauer

Native-browser-first parts sourcing for the whole electronics industry — drive the user's signed-in Chrome/Edge (adom-browser-extension) for real logins + no bot-walls. Root strategy skill + one sub-skill per website. chip-fetcher's default.

Overview Files Skills Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
chip-sourcing-skillpack / SKILL.md
Download

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_*.

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