kicad-happy reads your schematic and then does the arithmetic you skipped

The reports are arithmetic, not adjectives

The example output in the readme is what makes this project interesting, so read the numbers rather than the framing. The power tree section traces a regulator from input to load and computes the output voltage from a feedback divider, reporting a ratio of 0.155 and an output of 3.87 volts against a nominal 5 volt rail, then estimates dissipation. That is a review finding, not a description. A second table computes the corner frequency of every RC network it recognises: 15.9 Hz from one pair, 169 Hz from another, 1.03 kHz from a third, and labels each as a low-pass, a debounce or signal conditioning. A divider is computed at a ratio of 0.500 and identified as voltage sensing. A crystal is checked by computing the load capacitance from its values and comparing it against a target, reporting 14.0 pF against 18 pF and a percentage shortfall. Each of these is a computation a reviewer can do with a calculator and usually does not, which is exactly why automating it is worthwhile. The framing matters too: the report is organised as a chain of evidence from a detected network to a computed value to an interpretation, so you can disagree with the interpretation without discarding the number.

The connector audit is the part most likely to be useful on a real board

Of all the checks, the connector protection audit is the one that generalises. The example shows nineteen connectors examined, some marked as covered and some flagged, with the reasoning given for each. A USB-C port has an ESD clamp on the data lines and is marked as partial because of the ratio of signal pins to ground pins, which is the same metric the production-readiness section calls out separately as thirteen signal to one ground against a recommended maximum of three to one. Fuses get their current rating noted. Then four categories are flagged as having no protection: a pin header, the motor outputs, the servo connectors and a sensor port, with the motor outputs annotated as exposed to back-EMF. This is a systematic enumeration rather than a spot check, and it is the kind of pass that a designer does once, carefully, when they are tired of the board. Two limits are worth naming. The check is about the presence of protection, so a design with no ESD clamps produces a long list of findings that may all be correct and still describe a hobby board. And back-EMF on motor outputs is a different failure mode from ESD, so grouping them under one heading is a simplification. Treat the output as a checklist to triage, not a verdict.

Production readiness and the bill of materials lock

The production-readiness section is where the project stops being a simulator and starts being a gate. It reports the bill of materials lock percentage, decoupling totals per rail, and connector ground distribution. In the example the lock is zero percent with no manufacturer part numbers assigned, which the report labels as prototype stage, and the decoupling is broken down by rail with the microfarad totals for motor, logic and the 3.3 volt domain. That decomposition is the useful part, because a single total number for a board tells you nothing while a per-rail figure tells you which domain is under-capped. The bill of materials lock metric is also a proxy for something broader: a design with no part numbers cannot be sourced, cannot be quoted, and cannot have its values checked against datasheets, so a zero here is an early warning that several later capabilities will be degraded. The example reports also reference a validation document and a set of separate topic documents in the repository, including one on datasheet extraction, one on electromagnetic compatibility pre-compliance, one on simulation integration, one on signal integrity, and one explaining how the whole thing works from parsing onward. That is a documentation structure worth noting: this project ships its reasoning, not just its conclusions.

The scaling claim: subcircuit identification, not just passives

The readme makes a specific claim about what the agent identifies: functional blocks and how they connect, not just passive components. The example table backs it with five categories on a robot controller board. A motor drive described as nine P-channel MOSFET switches in transistor-driven H-bridges, with a part number. Filters described as RC signal conditioning at three named frequencies for input filtering and debounce. A lighting chain of addressable LEDs on a general purpose pin with an estimated 60 mA draw. A sensor interface alongside a crystal oscillator with load cap validation. Protection covering an ESD clamp on the USB data lines and two input fuses at different current ratings for signal and motor paths. Reading this table, the claim is defensible in a specific sense: it has grouped a board's parts into blocks a hardware engineer would recognise, and it has attached values and part numbers to each group. What it has not done is verify the blocks work, and the distinction matters. Block identification is a precondition for useful review, since you cannot check a filter cutoff in a block you have not found, but it is not a substitute for simulating one. The readme is careful on this point, describing the result as something the agent found automatically, and the other repository documents cover simulation as a separate integration.

Five agent clients, five installation mechanisms, one known bug

The installation section is longer than most projects of this size would need, and reading it tells you the author tried to reach people rather than prescribe one tool. Claude Code has a plugin marketplace flow with two slash commands. OpenAI Codex has a built-in skill installer path and a manual fallback into a directory under the home folder. A third client has a plugin install command that takes a repository URL directly, a local-checkout variant, and enable and disable subcommands for turning the plugin off when you are not reviewing electronics, which is a nice touch for token cost. opencode is the fourth, where the instruction is to clone the repository and run the agent from the checkout:

git clone https://github.com/aklofas/kicad-happy.git
cd kicad-happy
opencode

That is four named clients, and the description also lists a fifth. The tooling detail worth reporting is the known bug: the readme says the update command may not detect new versions because of a tracked upstream issue, and gives the fix as deleting the plugin cache and marketplace directories before reinstalling. A project documenting a third-party tool's caching bug and a workaround for it is being unusually honest, and it is the kind of operational detail that saves an afternoon.

Continuous integration, and what a pull-request review would mean for a board

Beyond local use, the project runs as a GitHub Action for automated review on pull requests, and there is an action manifest and an action directory at the repository root plus a document describing the setup. This is the most interesting deployment choice in the repository and also the one to think about hardest. Running a hardware review on every pull request means a schematic change gets analysed before a human colleague looks at it, which is a genuine speedup for the class of errors described above, since nobody catches a wrong divider ratio by squinting. It also means the action has access to your design files and, depending on what the datasheet cross-referencing does, may reach out to component databases. Two questions follow that the readme does not answer: whether the action runs without publishing your design to a third party, and how a false positive is handled. A review bot that flags nineteen connectors on a prototype will be muted quickly, and a muted bot is worse than no bot. The repository also has a validation document, which is presumably the answer to whether these checks are themselves validated, and that is the document to read before trusting any of it on a board you care about. The maintenance picture is good: the recent releases are a correctness batch, a hierarchical connectivity batch, and a maintenance batch, in that order over about two months, with the last commit on 2026-09-13.

Editorial conclusion

Adopt kicad-happy if you design boards in KiCad and want a second pass that does arithmetic rather than opinions, because the checks it reports are the ones a human reviewer skips: feedback divider ratios, RC corner frequencies, crystal load capacitance, decoupling totals per rail, and signal-to-ground ratios on connectors. Do not adopt it as a substitute for a compliance test, since what it produces is a pre-compliance review that suggests which standards might apply rather than a measurement, and the readme describes it that way. Four things to verify. That the check is reproducible on your own designs, since a computed cutoff frequency or divider ratio is a number you can check by hand and a report full of numbers invites spot-checking. Which agent client you will drive it with, because installation differs across five of them and the readme notes a caching problem with version updates in one of them. That your components have manufacturer part numbers, since the readme's own production-readiness check reports the bill of materials lock as zero percent when none are assigned, and datasheet cross-referencing depends on them. And how much of the output you intend to act on, because a review that flags nineteen connectors in a design without ESD clamps is describing a prototype, not a defect. The licence is MIT and version 2.2.1 was released on 2026-09-01.

Frequently asked questions

Official sources

1. aklofas/kicad-happy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases