How often it is right, and how I know.

Latest untouched run

Round 4: 18 repositories, 30 KiCad projects, none used before. The engine was frozen (not edited) between the run and the review.

29 serious findings counted. 72% were correct and 41% were problems worth acting on. If my test-setup mistakes are counted against the tool, those fall to 58% and 33%.

Every round

Findings are blockers and warnings only. Notes are not counted. “Real” means a true problem or a true disagreement between the project’s own files. “Harmless” means correct but intentional or irrelevant in context. Round 3 had one project that produced 15 of its 24 findings, which flatters its percentage. Round 2 is the worst: a missing feature (buses between sheets) caused most of its wrong findings; it was fixed and later checked against KiCad itself.

What the wrong ones were (round 4)

• A hierarchical bus (CAN{H,L,GND}) that KiCad joins across sheets and this engine kept apart. Fixed, and the nets now match KiCad’s.
• Crystals whose chips have built-in load capacitors (SX1262, DS1307), so no external ones are expected.
• Capacitors that the author numbered U8 and U9, which the rule did not recognise as capacitors.
• A battery-backup supply pin and an unused I2C block that need no bypass.
• A regulator the rule did not know, and an isolated ground named CAN.GND that was not recognised as ground.

I fixed each of these and added a test that fails without the fix. After the fixes, the same round-4 boards give 19 serious findings with 14 real and 5 harmless, none wrong (two of the real ones had been hidden by a mistake in my test setup, which also got fixed). Do not read that as accuracy: I looked at those boards before making the fixes. The untouched number above is the honest one, and the next fresh round will be reported the same way.

If a part is really missing, does it notice?

I removed parts from real boards in memory (a bypass capacitor, a pull-up, a footprint) and checked whether the engine reported it. On 29 boards it had not been tuned on it found 235 of 246 (96%). On the 280 boards that were also used to tune the rules it found 1931 of 1990 (97%), which is a ceiling, not a promise.

What this does not show: it only tests removed parts, not wrong values or wrong wiring. The two weak spots are named here so you do not lean on them. ESP32 EN pull-up: found 12 of 23 on the tuning boards and 0 of 3 on fresh ones, because the rule stays quiet when a transistor, switch or connector shares the EN net (they may define the level), so a removed pull-up goes unseen on boards with an auto-reset circuit. Bypass capacitors: 63% on fresh boards, with most misses on rails shared between many parts or covered by another rule.

Does it read the schematic the way KiCad does?

I compared the nets this engine builds from .kicad_sch files with the netlist KiCad 10 itself exports (kicad-cli 10.0.7), as groups of pins. They match on 318 of 318 projects, 14,274 nets. That includes wires, junctions, local, global and hierarchical labels, power symbols and buses. The last mismatch was found on fresh boards in round 4 and fixed, so that figure is partly tuned too.

How the checker can be wrong

• It cannot see live JLCPCB stock, pricing or lifecycle. That is part of the paid check.
• It reads track width against JLCPCB’s minimum but does not measure the gap between tracks, pads or copper pours. Run KiCad’s DRC with JLCPCB’s minimum clearance, and JLCPCB’s own DFM check, for that.
• It cannot know your intent. A deliberately omitted capacitor looks like a forgotten one; that is the main source of “harmless” findings.
• Datasheet knowledge covers common parts and chip families, not every IC. Each report lists which ICs it could not compare.
• A clean report is not a clean board. It says what was and was not checked, and which checks did not run for lack of a file.

All 38 rules

Rules marked with only a schematic need nothing else. Rules that need a file you did not provide are shown as “not run” in the report, never as passed.