Inspecting and checking
why_connected
Say whether two pins are on one net, and by what route.
Usage
why_connected <Ref1> <Pin1> <Ref2> <Pin2>Angle brackets mark required arguments and square brackets optional ones. Available in the schematic editor. You can issue this yourself, and the AI agent issues the identical command — there is no second, hidden interface.
Arguments
Ref1Pin1Ref2Pin24 required, 0 optional.
Behaviour
Answers from the topology rather than from geometry, so it reports the REASON for each hop: along a wire, landing on a wire, through a junction, by label, by power symbol. When the two are NOT connected it says so — which is the more useful answer when a netlist has surprised you, because it means the connection you assumed is not there.
How the agent uses it
- The agent works in a perceive / act / verify / recover loop: it describes the design, issues
why_connectedor another command, checks the result, and undoes the change if the check fails. - Commands report what they actually did. A refusal is a result, not a silent no-op — which is what lets the agent recover instead of building on a change that never happened.
- Anything the agent can do here, you can do yourself, and the reverse.
Try why_connected in the editor
Free to start on macOS, Windows and Linux. Bring your existing KiCad and Altium libraries.