Automated Documentation Pipeline for KiCad 9 Boards

Oct 22, 2026 Last reply: 10 hours ago 2 Replies
Jump to replies (2)

The starting point here is a familiar pain: turning a finished board design into the paperwork a fab house expects, by hand, on every revision. The maker attacked that head on with a documentation pipeline built around KiBot running in CI/CD on top of KiCad 9, and shared it in case others find it useful.



The plumbing is what impresses me. GitHub Actions handles continuous integration and deployment, the repository runs on two branches with semantic versioning, and the Git flow moves a design through four stages: Draft, Preliminary, Checked and Released. Anyone who prefers keeping things on their own machine can run the whole system locally through Docker, and KiRI serves as the visual diff viewer for both schematics and layouts.



The generated output list is long. Fabrication documents come out with the stackup table, notes for fabrication, drill drawings with their tables, and testpoint tables all filled in automatically. Assembly paperwork gets images plus tables, crosses over DNP parts and text handled without hand work. There is an automated table of contents inside the schematic, 3D renders of the board dropped into various documents using KiCad's internal viewer with raytracing, an interactive HTML bill of materials, and a KiCost pricing spreadsheet that queries distributor APIs. Schematic PDFs stay synchronized with the CHANGELOG.md, and everything lands on a modern webpage for browsing the files. The example hardware, the 'Amulet Motion Controller' with an STM32G474, 3-phase inverter MOSFETs and dual onboard encoders, makes a convincing demo.



One rough edge remains: on Linux, the .github folder from the template still has to be copied manually into the project root.



Project by Vincent Nguyen. Watch it on their YouTube channel:

formatting link


Tying the schematic's Revision History page to the CHANGELOG.md looks like the cleverest piece to me. Revision notes generated from the same file the repo already uses should prevent drift between the PDFs and the actual project state. The trade-off is that it only works if the changelog itself is kept disciplined, but for anything past the Draft stage that seems a price worth paying.

A small setup script that copies the .github folder into the project root would erase the one manual step Linux users currently face, making the template fully hands-off on every platform. Beyond that, the KiRI visual diffs could be surfaced on the webpage next to the generated documents, so a reviewer could compare schematic and layout changes side by side with the release paperwork.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required