ZJUZhiyuCai KiCad Routing Review
Produce a reviewable native-board change with traceable evidence. Treat visual quality, geometry, connectivity, and electrical performance as separate questions.
Start with the actual project
Read the user's current constraints and identify the saved baseline. Keep existing authorized scope; this skill grants no additional permission to move components, change nets, publish data, or release hardware.
- Use the failure checklist before and after editing; the Chinese checklist includes historical examples.
- Read routing preferences when cleaning up paths or interpreting screenshots.
- Read the native workflow before scripting KiCad.
- Create a project-specific constraints record using the template. Example values are preferences, not universal PCB rules.
Construct readable routes
For the axial routing preset, favor horizontal and vertical main runs with short 45-degree transitions. Do not interpret fewer vertices as permission to draw long diagonal trunks. Do not replace a long diagonal with tiny alternating steps or split collinear segments to hide its length.
Adapt to the user's board: controlled impedance, RF, length matching, current, and return-path requirements can justify a different shape. Explain necessary detours with the actual obstacle and a tested alternative; a failed alternative does not prove the current route is optimal.
Use real pad and via coordinates. Avoid snapping to a routing grid and then adding tiny reconnecting segments. Prefer normal entry to rectangular pads when practical. Distinguish a segment's heading from the interior angle at a junction: a 45-degree diagonal is not a 45-degree acute corner.
Join branches at same-net pads or vias when practical. A junction centre inside a pad does not prove that the sharp copper notch is inside it. Inspect the union of actual pad, via, track, and taper copper. A centreline checker alone cannot authorize copper exceptions.
Preserve width, spacing, and protected geometry
Classify supply trunks, supply branches, ordinary signals, references, and local escapes. Netclass defaults do not independently enforce existing track widths. Use native rules and independent evidence appropriate to the project.
Record local neck-down width, pad, coordinates, reason, and total path length outside actual pad copper. Splitting the path into short segments does not reset its allowed length.
Specify whether spacing means centre distance or edge gap. For equal-width traces, centre distance 3W gives edge gap 2W. An unequal-width policy, parallel overlap threshold, fanout scope, and any exclusions must be explicit and project-specific. Keep native copper clearance separate from this spacing preference.
Check neighboring nets and all affected copper layers after simplifying a route. Through-hole copper remains an obstacle on multiple layers. Record authorized ordinary-via moves and size changes; compare protected thermal-pad vias independently.
Verify the delivered revision
Work on an independent candidate and protect unsaved editor changes. Preserve the project's frozen components, connectivity, pads, outline, footprints, stencil, and protected holes.
After editing and writing rules, refill and save the candidate, reload it, and generate evidence from that saved PCB. Run native ERC, DRC, unconnected and schematic-parity checks plus project-specific checks. Report ignored categories and unsupported geometry. Do not call a result a full-board pass when scopes were excluded.
The optional CLI in this repository produces centreline review candidates only. It does not inspect physical copper containment, enforce width exceptions, prove connectivity, or run native KiCad checks. If unavailable, use the guidance and project tools; do not invent a tool result.
When changing a checker, test the relevant failure and a normal control in temporary fixtures. Include split-collinear long diagonals, heading-versus-corner errors, width/neck violations, and spacing boundaries as applicable. Do not mistake an unrelated dangling-track warning for detection of the target fault.
Inspect native layer exports at both board and local scales. Deliver the native candidate, before/after views, change tables, and a report tied to the final file hash. Report changes in total route length rather than assuming that visual improvement improves electrical performance.
Complete the checklist with pass, fail, pending, or not applicable and evidence for each. Keep unresolved project constraints unresolved even when native DRC is clean. Separate routing remediation, engineer review, bench testing, and manufacturing release.
Learn without overgeneralizing
Add observed failures with their trigger, evidence, missed check, and corrective test. Mark preventive checks as preventive, not as historical incidents. Preserve filled project records when updating a checklist template. Do not turn a board-specific value or temporary exception into a universal requirement.