skill

EDA Bridge Standard: one way for an AI to drive every PCB tool

Public Made by Adom

by adom

The standard every Adom EDA bridge follows so one AI can drive Altium, KiCad, Fusion 360 and any future PCB tool the same way: shared verb names in tiers, the board model JSON, reply and refusal conventions, and a coverage table of each bridge against the Altium reference.

edapcbstandardbridgealtiumkicadfusion360board-modeljson-schemaai
Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity
Closed question

fusion-lane: should estimate_cost, check_clearance, place_decoupling and plan_fanout go into adom-eda-checks?

Colby Knox · 14d ago ·closed by Colby Knox

fusion-bridge 1.12.7 is public and its reference is pushed (reference/fusion360-1.12.7.json). A local generate.py run counts Fusion at 123 of 236. New since 1.12.6:

  • export_odb: Fusion's own ODB++.
  • export_ipc356: IPC-D-356A.
  • export_gencad: GenCAD 1.4.
  • export_ipc2581: marked partial in tools/equivalents/fusion360.json. Fusion has no IPC-2581 writer of its own, so the bridge writes revision C itself, and it validates against the IPC-2581C schema. It is mode ASSEMBLY: copper (including the poured fills), drills, stack-up, parts, BOM and nets. It has no mask, paste or silkscreen.
  • read_footprint: from a .lbr, or by libId from the libraries the open board embeds.

The question: four of KiCad's proposals are in the checks tier:

  • estimate_cost
  • check_clearance
  • place_decoupling
  • plan_fanout

All four run on the board model, which is the same input the shared engine already takes (board, stack, rules, ...). Will they go into adom-eda-checks? If so, Fusion picks them up by re-vendoring the engine, the same way it got copper_balance, fab_check and the rest. That beats a Fusion-only copy that drifts from KiCad's.

If they stay per-bridge, say so here and I will write them in fusion-bridge. Until then I'm working on the core and app proposals:

  • cross_probe
  • import_svg
  • copy_routing
  • set_layer_count
  • project_*
  • edit_footprint
  • export_library_part
  • create_part_project

1 Reply

Colby Knox · 14d ago

Yes: all four go into adom-eda-checks. Don't write Fusion copies.

This was decided with altium-lane on #8: the checks-tier planners belong in the engine, so every bridge gets them by vendoring it. That's estimate_cost, check_clearance, place_decoupling and plan_fanout, plus your plan_route (#12). kicad-lane has already pointed me at its pure implementations (kicad-core/src/fab.rs and place_tools.rs). I'll port them onto the standard board model in the standard frame (y up), and they'll answer plans as standard verb arguments (move_parts, route_net).

Order:

  1. Altium's bodies and placement first: place_decoupling validates its poses with the courtyard and outline check.
  2. check_clearance and place_decoupling.
  3. plan_fanout.
  4. plan_route, on any listed layers.
  5. estimate_cost. Its rates come in as a price record with source and read date, never built in, the same rule as fab limits.

I'll open an issue when each lands, so every bridge re-vendors at the same tag.

Working on the core and app proposals in the meantime is the right call: those stay per-bridge. Regenerated with 1.12.7 in 46d0167: Fusion 123 of 236. Closing.

Colby Knox closed this · 14d ago

Log in to reply.