app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed bug report

install_library silently does the wrong thing for a single-symbol file (registers each part as its own library, leaves Adom empty)

John Lauer · ·closed by John Lauer

Split out of #71 (Ray) rather than bundled into an unrelated fix.

A caller who wants "put this part into the Adom library" naturally reaches for kicad_install_library. That verb registers a library PAIR in sym-lib-table, so handed a single .kicad_sym it registers that part as its own library:

Library 'WS2812B-2020' already registered ... symbols/WS2812B-2020.kicad_sym

...while the shared Adom library stays empty. Every call returns ok. kicad_adom_library_status then correctly reports symbols: 0, and show_symbol cannot resolve anything — so the failure surfaces two verbs downstream of the mistake, with nothing pointing back at it.

The right verb is kicad_install_symbol. Nothing in install_library's output hints at that.

Ask: when install_library is handed a path that is a single .kicad_sym (or a file rather than a library pair), say so in the response and name kicad_install_symbol. It does not have to refuse — a hint on the success path is enough, because the current output is not wrong about what it did, only silent about it being the wrong tool for what the caller meant.

Reported by Ray in #71: "nothing in install_library's output hints that it is the wrong tool for putting a part into the Adom library."

1 Reply

John Lauer ·

Fixed in 0.9.278 (insiders; AdomLapper and ConfRoomROG are on it).

kicad_install_library still does what it did (registers the file as its own library), but when the file is a single-part .kicad_sym (one symbol, or up to three where one carries the file's name) the response now carries:

  • singlePartFile: true and symbolNames: [...]
  • a _hint that says the shared Adom library was NOT touched and names the right call: kicad_install_symbol {"filePath": "<that file>"} then kicad_show_library Adom

It is on both success paths, fresh install and the already registered no-op that Ray hit. A real multi-symbol library gets no hint.

Verified with the handler run against a real sym-lib-table file (three cases: single-part fresh, single-part already registered, five-symbol library). Not exercised live on a desktop, because there is no verb to remove a library row afterwards and I did not want to leave a test row in a box's table. SKILL.md carries the note as "from 0.9.278".

John Lauer closed this ·

Log in to reply.