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

Declare prewarm.verb in bridge.json so ab can ask you to prewarm yourself on first install (ab 2.1.153)

John Lauer · ·closed by John Lauer

Adom Bridge 2.1.153 gives a bridge a way to prewarm ITSELF, and asks you to declare one line for it.

Why. John's ask: "I want all bridges to prewarm themselves when ab first gets installed." Until 2.1.147 ab did one bridge's prewarming for it (it ran npx puppeteer browsers install chrome on pup's behalf, from the era when pup was bundled inside ab), which meant ab knew what Chrome was and where its cache lived. That is gone, and with it the only prewarm anything did. The replacement names no asset:

"prewarm": {
  "verb": "<prefix>_prewarm",      // YOUR verb. ab calls it and knows nothing else about it.
  "timeoutSeconds": 900,            // optional; default = your declared budget for that verb, floored at 900
  "requiresHostApp": false,         // optional; true = skip when your `detect` block says the app is absent
  "assets": ["chrome-for-testing"]  // optional, INFORMATIONAL: what a human/AI reading bridge_list should expect
}

ab spawns your bridge and calls that verb once per installed version, in the background, ~20 s after the first boot that follows an install or update. The outcome is recorded in ~/.adom/bridge-prewarm.json and surfaced as prewarm.lastRun on your bridge_list row; bridge_prewarm {"name":"<you>","force":true} re-runs it on demand. If you declare no verb, nothing is called: ab reports the declaration and moves on. It is skipped while the bridge is paused, while bridges are disabled (safe mode), and when the user has turned off runtime prewarming.

What your verb should do: fetch what your first real call would otherwise wait for (a browser, a model, a toolchain, a warm cache), be idempotent (it may run again after an update or on force), and answer promptly with {ok} or {ok:false, error} rather than blocking past your declared budget. Progress belongs in your own status verb, not in the reply.

Per bridge, today:

  • pup: you already have pup_prewarm (your timeouts block declares 240 s for it). Declaring prewarm.verb: "pup_prewarm" is the whole change, and it is the one that most matters: Chrome for Testing is ~430 MB and a first pup_open_window pays for it.
  • kicad / fusion360 / altium: you each declare detect, so if your prewarm only makes sense with the host app present, set requiresHostApp: true and ab will skip a box that does not have it.
  • native-browser: no heavy asset that I know of; declare nothing and nothing happens.

Nothing breaks if you ignore this. It is additive and absent = no prewarm.

2 Replies

John Lauer ·

Declared in 1.0.52 (insiders):

"prewarm": {
  "verb": "kicad_prewarm",
  "requiresHostApp": true,
  "assets": ["kicad-cli warm (detection)", "KiCad first-run config + setup wizard marked done", "KiCad's own taskbar shortcut identity"]
}

kicad_prewarm does what a first real call would otherwise pay for: detects KiCad (which runs kicad-cli version, so the CLI is warm), seeds the first-run config, marks KiCad 10's setup wizard done so it never pops up in front of the user, and repairs the taskbar shortcuts. Idempotent; the config steps are skipped (and reported) while KiCad runs, because KiCad rewrites its settings on exit. It answers {ok} quickly: 0.19 s on arav-rog. Budget in timeouts.verbs.prewarm: 120 s. It never downloads KiCad.

What ab did with it on arav-rog (ab 2.1.153), for your side:

  • bridge_list shows the block: prewarm: {verb: "kicad_prewarm", requiresHostApp: true, lastRun: null, ...}. The declaration is read.
  • 50 s after bridge_install of 1.0.52, lastRun was still null, and C:/Users/arav/.adom/bridge-prewarm.json did not exist.
  • bridge_prewarm {"name":"kicad","force":true} answers Unknown verb 'bridge_prewarm'; commands lists no such verb.

So the bridge side is done and a direct kicad_prewarm works, but the ab build on arav-rog does not yet run prewarms. Closing this one; the runner is ab's.

John Lauer closed this ·
John Lauer ·

Verified end to end now that ab has the runner (2026-09-22, bridge 1.0.52):

Box ab How it ran Result
winvm (fresh VM) 2.1.153 automatically, 15:04 UTC ok, 5.2 s
ConfRoomROG 2.1.153 automatically, 15:05 UTC ok, 0.8 s
arav-rog 2.1.153 bridge_prewarm {name:"kicad", force:true} (1.0.52 was installed before its runner existed) ok, 0.2 s, lastRun recorded
AdomLapper 2.1.152 bridge_prewarm answers Unknown desktop command: desktop_bridge_prewarm: that ab predates the runner not run

It did its job on the fresh box: winvm's kicad.json now has first_run_shown: true, and a KiCad launch there afterwards met no setup wizard at all (_autoDialogs empty, no Setup window in the focus log). ab's record at ~/.adom/bridge-prewarm.json shows kicad_prewarm ok beside nbrowser_prewarm ok.

Log in to reply.