• Overview
• Why “trustworthy” is the whole point
• One computation, three outputs
• CI-first, viewer second
• Try it
• Non-goals and what’s next

Overview

You’ve spun rev B of a board, sent it to the fab, and somewhere between rev A and rev B something changed on a copper layer. Which pad? How much? Did that last-minute clearance nudge actually land, or did it quietly not? Staring at two Gerber renders side by side is how mistakes get to production.

etchy points at two revisions of a board’s fabrication output (Gerber, Excellon drill, pick-and-place) and shows and measures exactly what changed. It’s the ground-up Rust successor to my Python Gerber-Diff-Tool, and as of v0.1 it is public and usable. Dual-licensed MIT / Apache-2.0.

etchy old/ new/     # terminal summary; exit 0 = no diff, 1 = diff, 2 = error

Why “trustworthy” is the whole point

A diff tool that occasionally misses a change is worse than no tool, because it teaches you to trust it and then lets you down on the one board that mattered. So the design is built around not lying to you:

• Same-board revisions only. Point it at two different boards and it fails loud rather than emitting a confident, meaningless diff.
• No silent misses. The engine is backed by a golden-image corpus plus property and fuzz tests. The change either shows up or the run fails, never a quiet wrong answer.

The limits are written down too, in the repo’s trust document: what etchy guarantees and what it deliberately doesn’t.

One computation, three outputs

Everything comes from a single per-layer polygon boolean diff (added = B - A, removed = A - B), computed once and presented three ways:

1. A resolution-independent SVG overlay: the classic red/green added/removed view, but as vectors, so it stays crisp at any zoom. Also available as one self-contained HTML report.
2. A change heatmap for the question “where do I even look?” on boards where the diff is a handful of pads in a sea of unchanged copper.
3. Magnitudes: changed area (mm²) and region count as JSON, so CI can gate on how much changed, not just whether anything did.

Moved, rotated, added and removed components show up as placement markers, and schematic PDFs get a page-by-page pixel diff.

CI-first, viewer second

etchy lives in a pipeline first and on your desktop second. It has proper exit codes, per-layer thresholds, git refs (etchy v1.0 HEAD fab/ diffs two commits with no checkout) and JSON output. A GitHub Action posts a sticky per-layer table on every pull request that touches Gerbers:

- uses: Cimos/etchy@v0.1.1
  with:
    old: fab/rev-a
    new: fab/rev-b
    comment: true

Gating is by magnitude and location, so silkscreen churn can be ignored while copper changes over 0.5 mm² fail the build:

etchy old/ new/ --gate-layers copper --fail-on-area 0.5

It ships as small static binaries and an ~11 MB distroless container.

For poking around a diff by hand there’s a native egui desktop viewer (Windows, macOS, Linux) with overlay, before/after, split and swipe modes, plus a web build. It’s a separate binary that never gets compiled into the headless builds, so CI stays lean.

Try it

The repo ships two revisions of a real board, my open Mad_RP2040, so there’s something to diff straight away:

etchy crates/etchy-gui/assets/demo/old crates/etchy-gui/assets/demo/new --html diff.html
# 10 of 13 layers changed

Binaries, installers and the container are on the releases page.

Non-goals and what’s next

etchy deliberately does not do net or connectivity diff, BOM diff or DRC. It diffs fabrication output, trustworthily, and stops there. The other jobs have other tools (kitium covers a chunk of the KiCad-side CI story).

Next up is reading KiCad .kicad_pcb files directly, so you can diff the design and not just the fab output, with a list of changed objects alongside the layer diff. Altium .PcbDoc follows.

-SM

• Overview
• What changed from the old rules
• One source of truth per fab
• Generic: design before you pick a fab
• The green DRC that checked nothing
• Using it

Overview

kicad-druid is a set of KiCad custom design rules (.kicad_dru) that match what JLCPCB and PCBWay can actually make. Drop the file for your order into your project and KiCad’s DRC flags anything the fab would bounce, on your screen instead of in their review queue.

It replaces my earlier KiCad Custom Design Rules repo, which is now in the archive. Same idea, rebuilt properly: the rules are generated rather than hand-edited, every variant is checked by KiCad in CI, and there is a new set of rules that works for either fab. MIT-licensed, works on KiCad 8, 9 and 10.

What changed from the old rules

One source of truth per fab

Each fab’s published capabilities live in one TOML file (capabilities/JLCPCB.toml, capabilities/PCBWay.toml). A small Python script generates every .kicad_dru from it, plus a side-by-side comparison table of the two fabs. CI regenerates the files and fails if anyone hand-edits the output, so the rules can’t drift away from the capability table they came from.

That also killed the old “uncomment the right block for your layer count” step, which was the easiest way to get these files wrong. You now pick the whole file that matches what you’re ordering:

PCBWay files also ship impedance net classes (50 Ω single-ended, 60–120 Ω differential) as starting points for the fab’s default stackup.

Generic: design before you pick a fab

Plenty of boards get designed before anyone has decided where they’ll be built. The Generic/ rules take the stricter of the two fabs for every limit: the larger minimum, the smaller maximum, and any rule either fab needs. A board that passes Generic passes at both. Once the fab is settled, switch to that fab’s file and the limits relax. Generic is derived in code from the two fab files, so it follows any capability update automatically.

The green DRC that checked nothing

This is the part I’m happiest with. If KiCad can’t compile a rules file (one typo, one unknown layer name), it drops the rules, and kicad-cli pcb drc reports a clean run with exit code 0. No warning, empty stderr. Your CI goes green while not a single custom rule ran.

kicad-druid’s CI guards against that. It runs KiCad’s DRC on a paired test board for every one of the twelve rule files, and before each run it appends a sentinel rule that must always fire. If the sentinel isn’t in the report, the file didn’t compile, and the job fails. It goes at the end of the file because some errors drop only the rule they’re in and everything after it, while others drop the whole file. Either way, the sentinel goes missing.

The linter also catches the quieter mistakes: lowercase item types like 'track' that KiCad silently never matches, and layer display names like F.Silkscreen that stop resolving the moment a board is imported from Altium or renamed.

Using it

1. Copy the .kicad_dru matching your order from JLCPCB/, PCBWay/ or Generic/ into your project folder.
2. Rename it to match the project: your-project.kicad_dru.
3. Run DRC (F8). Check Board Setup > Design Rules > Custom Rules once for errors, since KiCad won’t tell you otherwise.

Releases and the full rule comparison are on GitHub. It started as a fork of labtroll/KiCad-DesignRules by Morten Hattesen, with that history kept.

-SM

• Overview
• Why bother
• What you get
• Built from the manual
• Trying it

Overview

Omron Adept robots are programmed in eV+ (and its older sibling V+), a language that dates back decades and shows it. The official editor does the job, but it’s a long way from a modern code editor. vscode-evplus brings eV+ / V+ programs (.pg, .v2) into VS Code: highlighting, hover help, completion, diagnostics and navigation. MIT-licensed.

Why bother

eV+ has a few traps that bite anyone coming from another language. The big one: everything after a ; is a comment. So this line

a = 1 ; b = 2

only assigns a. Nothing warns you, the robot just doesn’t do the second half. Add a large program split across many .PROGRAM blocks, GOTO labels, and a reference manual you have to keep open in another window, and small mistakes are easy to make and slow to find. An editor that knows the language catches most of them before the program ever reaches the controller.

What you get

• Highlighting for control flow, instructions, functions, system switches and parameters, radix numbers (^HFF, ^B1010), precision points (#pick), string variables ($name), labels and .PROGRAM / .END blocks, with folding.
• Hover shows the manual’s syntax line for the keyword under the cursor.
• Completion for 260+ keywords with their type and syntax, and signature help that tracks which parameter you’re on.
• Diagnostics for code hiding after a ;, GOTO targets that don’t exist, and unpaired .PROGRAM / .END.
• Navigation: every program in the Outline panel, go-to-definition and find references across the workspace, and Ctrl+T to jump to any program by name.
• Snippets and auto-indent for the usual blocks (IF, WHILE, DO/UNTIL, FOR, CASE).

Built from the manual

The keyword data isn’t typed in by hand. A script reads an extraction of the eV+ Language Reference Guide and generates both the keyword list (name, type and syntax for each entry) and the keyword patterns in the grammar. When the manual changes, the extension is regenerated rather than patched. Only the syntax lines are committed. If you own the manual you can regenerate locally with the fuller descriptions for richer hover text.

The grammar is covered by tokenisation snapshot tests, so a change that breaks highlighting on an existing construct fails the test run.

Trying it

It isn’t on the marketplace yet. Build it from source:

npm install
npm run package
./install.sh

install.sh installs the extension on both the WSL and Windows sides of VS Code. Reload, open a .pg file, and go.

Source is on GitHub.

-SM

• Overview
• The dumb tedious step
• The trick: no auth at all
• Running it
• Know what you’re trading

Overview

Cimos/Altium-Push-to-DigiKey takes an Altium BOM and turns it into a DigiKey shopping list you can open and buy. One command. MIT-licensed.

The dumb tedious step

Between “the design is done” and “the parts are on order” sits a chore nobody enjoys: copying manufacturer part numbers out of a BOM and pasting them into a distributor cart, line by line, minding quantities and skipping the DNPs. It’s ten boring minutes that’s easy to get subtly wrong, and you do it every spin.

This automates exactly that step and nothing more. It reads the BOM Altium already emits — either the raw CSV from a BOM Output Job or the normalised JSON from a review-pack pipeline — parses it tolerantly for part number, quantity and designator, skips DNP rows and anything with an empty MPN or zero quantity, and hands you back a link.

The trick: no auth at all

The neat part is there’s nothing to set up. No API key, no OAuth dance. It POSTs to DigiKey’s anonymous mylists/api/thirdparty endpoint — the same one Digi-Key’s own official KiCad plugin uses — and gets back a short URL like digikey.com/short/<code>. You open that in a browser and the list drops into whatever account you’re logged into. Anonymous on the way out, account-tied the moment you click. An authenticated direct-to-account mode over OAuth2 is on the list, but for the common case the no-auth path is the whole appeal.

Running it

Python 3.8+, installed straight from the repo:

pip install git+https://github.com/Cimos/Altium-Push-to-DigiKey.git

Then point it at a BOM. --dry-run parses and reports without sending; --open launches the browser for you; --tags labels the list.

Know what you’re trading

Convenience like this always costs something, so here’s the bill, stated plainly:

• The short URL is link-shareable until you claim it — anyone with the link can grab the list, so treat it like a secret.
• The endpoint isn’t formally documented as a public API, and there’s no per-user authentication on the POST. It works because the official plugin uses it, not because DigiKey promised it would.
• There’s no compliance filtering. NDAA and any regulatory concerns are yours to handle upstream, before the parts ever reach this script.

None of that is a dealbreaker for ordering your own prototypes. It’s worth knowing before you wire it into anything that matters.

-SM

• Overview
• Why hand-assembly needs this
• Standing on the OpenScopeProject’s shoulders
• Getting it out of Altium

Overview

Cimos/interactivehtmlbom4altium2 generates an interactive HTML BOM from an Altium Designer project — a single self-contained page where you can search a part and have its footprint light up on the board, and click a footprint to jump to its BOM row. MIT-licensed.

Why hand-assembly needs this

If you’ve ever hand-populated a dense board, you know the loop: find the next line on the BOM, find that reference designator on the board, place the part, repeat two hundred times. On paper that means squinting between a printout and the PCB, losing your place, and occasionally soldering a 4.7k where the 47k goes.

An interactive BOM collapses that. Search or step through the list, the matching footprint highlights on a rendered board, and you never lose which parts are already down. For the KiCad crowd this has been a solved problem for years. Altium users have mostly been left doing it the paper way.

Standing on the OpenScopeProject’s shoulders

I didn’t invent the good part here. The InteractiveHtmlBom project by the OpenScopeProject is the tool everyone means when they say “iBOM,” and its output format is the thing worth being compatible with. What was missing was the front half for Altium — the bit that reads the design and produces data in that shape.

So this is that half. It pulls PCB and schematic data through Altium’s Pascal scripting API, renders silkscreen, pads, text and drawings, and writes out HTML, a JS bundle, and JSON that matches the InteractiveHtmlBom schema — so it slots straight into the ecosystem that already exists. Optional tracks, zones and a netlist get you live net highlighting on top.

It’s quick enough to live in your workflow: roughly five seconds for a 200-component board, around fifty for a genuinely dense 2000-part one.

Getting it out of Altium

Two ways in, depending on how you work. Run it as a script from the PCB layout and a configuration GUI comes up — good for one-offs. Or add the .pas to an OutJob as a Report Output, and the interactive BOM gets generated as part of your normal output run, right next to the gerbers and the assembly drawings, every time.

-SM

• Overview
• A board isn’t done when the layout is
• The jobs
• What it expects from your repo
• Why it’s its own repo

Overview

Cimos/kibot-config is a GitHub Action and a small library of KiBot configs that turn a KiCad project into a complete fabrication datapack — drawings, gerbers, BOM, pick-and-place, 3D STEP, Blender renders, panels, visual diffs — on every push.

A board isn’t done when the layout is

Finishing the layout feels like the end. It isn’t. Then you export gerbers, generate the drill files, produce a BOM in whatever format the assembler wants this week, a pick-and-place with the right origin, a STEP for the mechanical team, a render for the pull request, and a panel drawing for the fab. Do that by hand, from menus, every time you change a resistor, and you’ll eventually ship the old gerbers by accident.

The fix is the same one CI applies to software: never generate release artefacts by hand. Let a machine rebuild the whole datapack from source on every push, deterministically, so what you hand to the fab always matches the commit.

The jobs

Each config is a self-contained stage you can run on its own:

• build-pcb — schematics, PCB PDFs, gerbers, BOMs, pick-and-place, KiCost data, stencils
• build-3d_model — STEP exports, simple and full
• build-2d_images — four Blender renders (top/bottom × angled/straight)
• build-video — a rotating-board frame sequence
• build-diff — KiRi and git-based visual diffs of the PCB and schematic
• build-panel — drawings for panelized boards

What it expects from your repo

Almost nothing, on purpose. It auto-detects a single top-level *.kicad_pro, reads an options.yaml for preflight overrides, filters and variants, and an optional panelization.yaml if you’re panelizing. Add a workflow that checks out your project and this repo, then names the config you want:

- uses: Cimos/kibot-config@main
  with:
    config: build-pcb-kibot.yaml

Why it’s its own repo

This started life inside Mad_RP2040 as that board’s pipeline. It was obviously not board-specific — nothing in “export the gerbers” cares which board it is — so I pulled it out so any project could reuse it without copy-pasting a .github folder around. It’s BSD-3-Clause for the same reason: I’d rather people lift these into their own boards without having to think about the licence.

-SM

Superseded: these rules have been rebuilt as kicad-druid, with generated rule files, a Generic set for either fab, and full KiCad DRC in CI. Use that one for new projects.

Table of contents

• Overview
• The check KiCad doesn’t do
• Rules that can’t quietly rot
• Using it
• The one gotcha

Overview

KiCad’s DRC will happily tell you your board is perfect. Your fab house may disagree. Cimos/KiCad-CustomDesignRules is a set of .kicad_dru files that teach KiCad what a given manufacturer will actually accept — right now, JLCPCB and PCBWay. MIT-licensed, and by some distance the most-used thing I’ve put on GitHub, which tells you how common the problem is.

The check KiCad doesn’t do

Default DRC checks that your board is internally consistent: nets don’t short, clearances match the netclasses you set, courtyards don’t overlap. What it has no opinion on is whether the 0.1 mm trace you just routed is below your fab’s floor on their cheap process, or whether your annular ring survives their drill tolerance.

Every fab publishes a capability table. Almost nobody transcribes it into KiCad’s custom-rules syntax, because the syntax is fiddly and the table is long. So the board passes DRC, gets to the fab, fails their review, and bounces back with a note about minimum annular ring — usually after you’ve already paid and started waiting.

These files are that transcription, done once and checked, so the failure happens on your screen instead of in their inbox.

Rules that can’t quietly rot

The failure mode for a project like this is subtle: KiCad changes a token, a rule silently stops matching anything, and the file still “passes” because it’s now checking nothing. Green tick, zero coverage.

So every fab folder ships its .kicad_dru next to a paired test board — a real .kicad_pcb with footprints placed to trip each rule on purpose. If a rule stops biting, the test board stops failing where it should, and that’s caught. On top of that there’s a Python linter for syntax and a headless KiCad 8+ command-line DRC pass, so the whole set is machine-verified rather than eyeballed. Authored against KiCad 8 syntax, forward-compatible with 9 and 10.

Using it

Copy the relevant file into your project, rename it to match, then Board Setup → Design Rules → Custom Rules, and run the checker with F8. That’s the whole workflow.

The one gotcha

A lot of rules ship with alternates commented out — different values for different layer counts or copper weights. Those aren’t automatic. Pick the variant that matches the board you’re actually ordering, and read the comments before you trust the result. A green tick against the wrong copper weight is just a different way to be wrong.

Found a capability the rules get wrong, or want a fab I haven’t added? Open an issue — a fab’s spec sheet plus a failing example is exactly what makes these better.

-SM

• Overview
• Don’t migrate, re-derive
• What runs on every PR
• What I’ll say works, and what I won’t
• Dropping it into a repo

Overview

Plenty of hardware teams live in Altium and aren’t going to stop. But KiCad’s toolchain is free, headless and scriptable in a way Altium’s isn’t, which makes it a genuinely good reviewer even when it’s a bad fit as the editor. Cimos/kitium sits in that gap: a CI/CD gate that converts an Altium project to KiCad and validates it on every pull request. MIT-licensed.

The name is Ki(Cad) welded to (Al)tium, with a nod to Zeno of Citium — founder of Stoicism, which is about the right temperament for something that reviews your board dispassionately and has no feelings about your routing.

Don’t migrate, re-derive

The instinct when you want KiCad’s tooling is to migrate the project. That’s a one-way door and a merge-conflict nightmare on a board that’s still changing.

kitium takes the other path: Altium stays the single source of truth, and the KiCad files are re-derived from it on every run and then thrown away. Nothing generated is committed back. The KiCad project is a disposable artefact whose only job is to be inspected — so there’s never a second copy to keep in sync, and never a question about which one is real.

What runs on every PR

1. Find the Altium project — .PrjPcb / .PcbDoc, including multi-board setups.
2. Convert each board headlessly with kicad-cli pcb import --format altium.
3. Push it through KiBot: DRC, gerbers, 2D and 3D renders, visual comparisons.
4. Cross-check the board’s BOM against an exported Altium CSV.
5. Post the lot back onto the pull request — renders, diffs, downloadable artefacts.

What I’ll say works, and what I won’t

I’d rather scope this honestly than let a green badge imply more than it checks:

• Solid. PCB conversion, DRC, gerbers, renders. These are native headless operations and they hold up on real boards.
• Partial. The visual diff config is in place but the base-reference wiring isn’t finished. BOM validation leans on the Altium CSV cross-check — not by preference, but because a converted KiCad board simply doesn’t carry MPN and supplier metadata to check against, so the CSV is the only honest source.
• Not done. Schematic ERC. It needs fragile GUI automation to get the netlist out of Altium cleanly, so it stays a non-blocking stretch goal rather than a promise I quietly break.

Dropping it into a repo

It’s a Docker-based GitHub Action on the kicad/kicad:10 image with KiBot and the KiCad CLI, shipped as a pre-built GHCR container so it doesn’t rebuild the world on every run:

- uses: Cimos/kitium@v0.1.0
  with:
    project: hardware/MyBoard.PrjPcb
    bom_csv: hardware/MyBoard_BOM.csv
    drc: block          # fail the gate; use "report" to only comment
    github_token: $

It’s v0.1.0 — end-to-end PCB validation is proven on real Altium fixtures. If you run it against a board it chokes on, that’s the interesting case; an issue with the project is worth a lot.

-SM

• Overview
• Why a test board
• Rev A: 2-key test board
• Rev B: 4×4 anything keypad
• KiBot + GitHub Actions pipeline
• Building the boards
• What’s next
• Renders

Overview

Mad_RP2040 started in August 2024 as a 2-key test board for the RP2040, before I committed to it on a full split keyboard. It’s now a 4×4 backlit “anything keypad” with USB-C, per-key SK6812MINI-E LEDs, a TRS connector, and a KiBot CI pipeline that spits out gerbers, BOMs, position files, 3D renders, panel data and visual diffs on every push.

This is what each rev was and what went wrong building them.

Why a test board

I want to design my own split keyboard from scratch. A Corne-class board has a lot going on at once: matrix, diodes, controller, USB, per-key RGB, OLED, TRS interconnect, possibly battery management. Get the controller wrong and you can’t trust anything else on the board.

Easier to prove the controller block on its own first. Small board, get the RP2040 reference design and USB-C right, prove bootloader and toolchain, then copy that block into the bigger board.

That’s Rev A.

Rev A: 2-key test board

Rev A is small. The whole BOM:

• RP2040 with the reference circuit from the Hardware Design with RP2040 guide — 1.1V core LDO, 3.3V LDO, QSPI flash, crystal and load caps, boot select button.
• USB-C with both CC pins pulled down through 5.1k.
• 2 × MX hot-swap sockets, each with a 1N4148W diode.
• Power LED, reset button, four mounting holes.

No backlight, no TRS, no battery. Just enough to validate the parts I wanted to copy forward.

Archived as a zip in resources/rev_a/ along with the step models, if you want the minimal RP2040 ref design without the keypad on top.

Rev B: 4×4 anything keypad

Once Rev A worked I started on Rev B. First pass was 4×5; once I tried to actually place 20 keys plus 20 LEDs and their decoupling caps it shrank to 4×4.

What Rev B added on top of Rev A:

• 16 keys in a 4×4 hot-swap grid. Generic macropad layout — bind it to whatever you want in QMK.
• Per-key SK6812MINI-E LEDs, daisy-chained on a single PIO line. The -E variant has the LEDs aimed up through the switch hole, which is what north-facing switches need for shine-through caps.
• TRS connector on a header strip along the top edge, so the board can run standalone or as one half of a future split.
• Migrated all passives to 0603. Rev A was a mix of 0603 / 0805. JLC assembly charges least for 0603, so everything went 0603.
• Supplier metadata in the BOM. Every passive has LCSC, Digikey and Mouser part numbers, sorted by reference designator descending.
• 1×2 panelisation with KiKit tabs, rendered alongside the single-board build.

Smaller fixes along the way: hidden text on fab layers, 3.3V LDO swapped from adjustable to fixed, USB diff pair impedance recalculated and rerouted, diode footprints redrawn to silk the cathode, min track spacing tightened in the DRU.

KiBot + GitHub Actions pipeline

The most reusable thing to come out of this project is the CI. Every push to main runs five GitHub Actions jobs against the KiCad project:

It runs on GitHub-hosted runners, driven by KiBot and a shared kibot-config repo via submodule. About two minutes wall time per push, artifacts on the run page.

Same idea as software CI: when fab needs files, I don’t want to be opening KiCad and exporting ten things by hand.

Building the boards

Both revs got fabbed and assembled. Both had a bug.

Rev A had D+ and D- swapped at the USB-C connector — host reported “USB device not recognized”. Two scalpel cuts, two bodge wires, enumerated fine. The schematic correction went into Rev B before Rev B was sent to fab.

Rev B came back in November 2025. The controller side came up clean — USB enumerated, bootloader behaved, SK6812MINI-E chain lit on the first WS2812-style driver. The matrix didn’t. First row and first column scanned, nothing past them did. Wiring error in the matrix beyond row/col 1. Both assembled boards had the bug because both came off the same gerbers; both got the same cut-and-bodge.

The matrix fix is not in main yet. The two boards work bodged and respinning gerbers to fix units I already own hasn’t been worth the time. Fab from main today and you’ll need the same mod.

Rev A still did what it was supposed to. The D+/D- swap was exactly the kind of bug worth catching on a small cheap board before it shipped into a 16-key one. The Rev B bug was in the matrix, which is new to Rev B and never got a test pass, so de-risking the controller didn’t help with it.

What’s next

Mad_RP2040 is done. The CI is reusable, and the controller block is now a known-good copy-paste in the mad_lib submodule, ready for the full split.

If you want to fab one: clone the repo, grab the latest green CI run, and the JLCPCB folder in the PCB datapack has what JLC needs. MIT-licensed. Note the matrix bug above.

Renders

From the CI on the most recent push to main.

-SM

• Overview
• Why this exists
• What it does
• What it doesn’t do
• Install
• Pairing it with KiCad
• What’s next

Overview

Just shipped a small Visual Studio Code extension: KiCad Custom Design Rules. Source on GitHub at Cimos/vscode-kicad-dru. It adds proper syntax highlighting and snippets for .kicad_dru files in VS Code, and nothing else. Specifically nothing else — more on that below.

Marketplace ID: cimos.kicad-dru. MIT-licensed. Currently v0.0.1.

Why this exists

KiCad’s only built-in editor for custom design rules is the single-line textbox in Board Setup → Custom Rules, plus a Check Rule Syntax button. That’s fine for a one-liner. The moment your DRU file has more than two or three rules — multi-class clearance, manufacturer-specific via stacks, a stack of disallow constraints — you want a real editor. Multi-cursor. Search. Folding. Colour that distinguishes a condition operator from an A.NetClass accessor from a layer name from a string literal.

The KiCad forums make the demand obvious. There’s a long-running megathread where people post DRU snippets and ask grammar questions, and at least one user spelled it out plainly: “externally I have a better text editor with syntax highlight and the possibility to search things and multiple cursors.” They were clearly already editing in VS Code; the editor just wasn’t doing anything useful.

The closest existing extension is DanielMeza.kicad-syntax-highlighter. It declares .kicad_dru in its file-extension list, but the underlying grammar is a generic KiCad s-expression highlighter — keywords like condition, constraint, disallow, A.NetClass, intersectsArea all colour as plain atoms. Functionally you get matched parens and not much else. oaslananka.kicadstudio is the heavyweight all-in-one, and it does great workspace-level things, but it doesn’t ship a TextMate grammar that knows the DRU sub-language either.

Nobody had bothered to write a grammar tuned to DRU specifically. So I did.

What it does

• Syntax highlighting scoped to .kicad_dru. Top-level keywords (version, rule, constraint, condition, layer, severity, disallow), every constraint type (clearance, hole_clearance, track_width, length, assertion, …), the token-expression accessors used inside condition strings (A.NetClass, B.intersectsArea, …), operators, severities, layer names, comments, and numbers with units all colour distinctly.
• Snippets for the rule shapes you keep re-typing: starter rule block, clearance by netclass, disallow, length matching, via and track sizing, hole-to-hole, assertion. Type the prefix in a paren context, hit tab.
• Editor niceties: # line comments toggle with Ctrl+/, parens match, top-level (rule …) blocks fold, brackets auto-close.

That’s the entire v0.0.1 surface. No extension.js, no activation event, no LSP, no telemetry. Just static JSON contributions: a TextMate grammar, a snippet file, and a language config. It loads when you open a .kicad_dru and does nothing the rest of the time.

What it doesn’t do

Worth being explicit, because the existing KiCad extensions on the marketplace tend to over-promise:

• No validation. This is a highlighter, not a parser. KiCad’s Check Rule Syntax button remains the source of truth for whether a rule is valid. If your file colours nicely but KiCad rejects it, KiCad is right.
• No schematic / PCB / symbol / footprint support. Those have their own grammar and their own existing extensions. Staying out of that territory is the whole point — DRU support there is incidental; here it’s first-class.
• No hover docs, completion, or diagnostics yet. All worth doing once the grammar settles. For v0.0.1 they would have meant shipping a real extension.js for what is currently three static JSON files. Tracked as future work.

Install

From the VS Code Marketplace:

ext install cimos.kicad-dru

…or search for “KiCad Custom Design Rules” in the Extensions view.

A .vsix is also attached to each GitHub release if you’d rather sideload:

code --install-extension vscode-kicad-dru-<version>.vsix

Pairing it with KiCad

KiCad ≥ 7 has Preferences → Configure Paths → External Tools. Point it at VS Code’s executable and you get one-click round trips: open the .kicad_dru file from the PCB editor, edit it here, save, switch back, re-run Check Rule Syntax. That’s the workflow this extension is built around.

What’s next

The big-ticket items for v0.1.x:

• Hover docs scraped from the KiCad documentation, so hovering on clearance or intersectsArea surfaces the constraint type’s docs without leaving the editor.
• Layer-name catalogue refresh — KiCad 9 added user-defined Cu layers and renamed some display strings, and the v0.0.1 grammar isn’t fully aware of them yet.
• Open VSX publish so VSCodium / Cursor / Theia users can install without bouncing through the MS marketplace.

If you hit a real .kicad_dru file the highlighter mangles, open an issue with a minimal snippet and I’ll take a look. PRs welcome too — DRU corner cases are exactly the kind of thing a small fixture catches and prose review misses.

-SM