node ~/.claude/skills/chip-fetcher-lite/server.js     # or: chip-fetcher-lite serve
chip-fetcher-lite app                                  # open as a Hydrogen webview

---
name: chip-fetcher-lite
description: >
  Lightweight wiki-first component staging area. Add a component (MPN or description), check the
  Adom wiki for KiCad/Altium/Fusion files, upload what's missing, then file the symbol + footprint
  + 3D model into the user's EDA libraries with per-manufacturer destinations and a clean 5-field
  symbol. A fast, low-context alternative to the full chip-fetcher. Trigger words — chip fetcher
  lite, stage a component, check the wiki for a part, do I have CAD for, add basic parts, file into
  kicad, send to library, upload component to kicad.
---

# chip-fetcher-lite

A low-context alternative to the full chip-fetcher. It does NOT scrape vendors, generate symbols,
or run concur. It reads the Adom wiki, stages files, and files them into the user's libraries.

## Running

```
node ~/.claude/skills/chip-fetcher-lite/server.js     # or: chip-fetcher-lite serve
chip-fetcher-lite app                                  # open as a Hydrogen webview
```

Server listens on `:7821` (`CFL_PORT` to override). Runtime data in `data/` (not shipped).

## What's automatic (no agent needed)

- **Wiki check** on add: `adompkg search` → classify exact/variant/none (MPN→slug normalize,
  passive detection, **description→MPN resolution** so "100nF 0402 capacitor" → `0402B104J160CT`).
  Bounded to 4 concurrent lookups so mass-adds don't spawn hundreds of processes.
- **File-availability boxes** per row (KiCad/Altium/Fusion + JLC) from the wiki page's files/metadata.
- **Library probe** (clicking *Probe libraries*): the SERVER shells `adom-desktop shell_execute`
  to scan the user's machine for their KiCad libraries (`~/Documents/KiCAD/{Symbols,Footprints,3D}`,
  etc.) and computes per-component destinations.
- **Send to library** (clicking *Send to library*): the SERVER downloads each component's CAD from
  `wiki.adom.inc/blob/component/<slug>/<file>` (or uses uploaded files) and files them onto the
  desktop via adom-desktop — footprint→`.pretty`, 3D→manufacturer folder, symbol→merged into the
  JLC category lib (trimmed to Reference/Value/Footprint/Datasheet/Description + LCSC). Creates and
  registers any missing libraries. Live progress in the top bar.

## The agent's role

Mostly: drive the UI for the user and answer "what's on the wiki." Useful things you can do:

- **Add parts in bulk** — POST `/api/components {name}` per part (dedup is automatic). Honour a
  concurrency-friendly pace; the server queues the checks.
- **Look up JLC/LCSC part numbers** the wiki doesn't have: `adom-parts-search search <mpn>` →
  the jlcpcb hit's `vendor_pn` (a `C…` number) → POST `/api/components/:id/jlc {jlcPart}`.
- **Open the webview** in the right pane (see DEVELOPING.md for the panel-id flow).

## Hard rules

- **Re-checking the wiki must NEVER delete user-uploaded files or user-edited fields** (JLC PN,
  edited names). The server preserves them; keep it that way.
- **Always reach the user's file system through adom-desktop**, never the container FS.
- Prefer what's on the wiki over the KiCad default library; use the KiCad **stock** footprint only
  for passives that aren't on the wiki.

See **DEVELOPING.md** for the full architecture + the gotchas that will bite a fresh session.