kicad

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

KiCad Project Analysis Skill

KiCad项目分析技能

Related Skills

相关技能

SkillPurpose
bom
BOM extraction, enrichment, ordering, and export workflows
digikey
Search DigiKey for parts (prototype sourcing)
mouser
Search Mouser for parts (secondary prototype source)
lcsc
Search LCSC for parts (production sourcing, JLCPCB)
element14
Search Newark/Farnell/element14 (international sourcing, reliable datasheets)
jlcpcb
PCB fabrication & assembly ordering
pcbway
Alternative PCB fabrication & assembly
spice
SPICE simulation verification of detected subcircuits
emc
EMC pre-compliance risk analysis — consumes schematic + PCB analyzer output
Handoff guidance: Use this skill to parse schematics/PCBs and extract structured data. Hand off to
bom
for BOM enrichment, pricing, and ordering. Hand off to
digikey
/
mouser
/
lcsc
/
element14
for part searches and datasheet fetching. Hand off to
jlcpcb
/
pcbway
for fabrication ordering and DFM rule validation. Always run
spice
for simulation verification during design reviews when any SPICE simulator is installed (check with
which ngspice ltspice xyce
). Always run
emc
for EMC pre-compliance risk analysis during design reviews when both schematic and PCB analysis are available. These are not optional — skipping them leaves value-computation errors and EMC risks undetected.
Before analysis: When the user asks to analyze or review a KiCad project, check whether a
datasheets/
directory exists in the project. If not, and DigiKey API keys are available (
DIGIKEY_CLIENT_ID
), offer to sync datasheets first: "I can download datasheets for your components before analysis — this enables pin-level verification and decoupling validation against manufacturer specs. Want me to sync them?" If the user declines or no API keys are set, proceed without datasheets — the analysis works without them but datasheet verification findings won't be available.
If you see a
DS-001
finding in the analyzer output
(severity
high
, detector
audit_datasheet_coverage
), the review cannot make any verified claim. Stop and either (a) run the datasheet sync via
digikey
/
mouser
/
lcsc
/
element14
(whichever has credentials/stock), (b) populate MPNs on the BOM parts, or (c) state explicitly in the report that every pin-level, electrical, and regulator finding is consistency only — do not use the words "verified", "confirmed", or "per datasheet" anywhere.
DS-002
(datasheets missing but MPNs set) and
DS-003
(partial MPN coverage) are softer variants with the same implication for the parts they cite.
技能用途
bom
BOM提取、补充、采购与导出流程
digikey
在DigiKey搜索元器件(原型打样采购)
mouser
在Mouser搜索元器件(备用原型采购渠道)
lcsc
在LCSC搜索元器件(量产采购,适配JLCPCB)
element14
在Newark/Farnell/element14搜索元器件(国际采购,可靠数据手册)
jlcpcb
PCB制造与组装下单
pcbway
备选PCB制造与组装服务商
spice
对检测到的子电路进行SPICE仿真验证
emc
EMC预合规风险分析 — 需结合原理图+PCB分析器输出
交接指引: 使用本技能解析原理图/PCB并提取结构化数据。将BOM相关工作交接给
bom
技能进行补充、定价与采购;将元器件搜索和数据手册获取工作交接给
digikey
/
mouser
/
lcsc
/
element14
;将制造下单和DFM规则验证工作交接给
jlcpcb
/
pcbway
若安装了任何SPICE仿真器(通过
which ngspice ltspice xyce
检查),设计审查时必须运行
spice
。**当同时具备原理图和PCB分析结果时,设计审查必须运行
emc
**进行EMC预合规风险分析。这些步骤不可省略 — 跳过会导致数值计算错误和EMC风险无法被检测到。
分析前准备: 当用户要求分析或审查KiCad项目时,检查项目中是否存在
datasheets/
目录。若不存在且有DigiKey API密钥(
DIGIKEY_CLIENT_ID
),主动提出先同步数据手册:“我可以在分析前下载元器件的数据手册 — 这能实现引脚级验证,并对照厂商规格去耦验证。需要我同步吗?”若用户拒绝或无API密钥,则直接进行分析 — 即使没有数据手册分析也能运行,但无法提供基于数据手册的验证结果。
若分析器输出中出现
DS-001
检测结果
(严重程度
high
,检测器
audit_datasheet_coverage
),则审查无法做出任何已验证的结论。需停止当前操作并选择以下方案之一:(a) 通过
digikey
/
mouser
/
lcsc
/
element14
(任选有凭证/有库存的渠道)运行数据手册同步;(b) 在BOM元器件上补充MPN编号;(c) 在报告中明确说明所有引脚级、电气和稳压电路的检测结果仅为“一致性检查” — 不得使用“已验证”“已确认”或“依据数据手册”等表述。
DS-002
(缺少数据手册但已设置MPN)和
DS-003
(MPN部分覆盖)是较轻微的变体,对涉及的元器件有相同的影响。

Design Review Contract

设计审查规范

When the user asks for a design review, complete report, ready-to-fab assessment, or anything equivalent, do not stop at running one or two analyzers and summarizing their findings. A design review in this skill has a stricter contract:
  1. Read the full workflow in this
    SKILL.md
    , not just the analyzer command sections.
  2. Read
    references/report-generation.md
    before writing the report.
  3. Run every applicable analyzer for the files present in the project, then say explicitly which ones were and were not run.
  4. Perform raw-file and datasheet cross-verification before claiming anything is "verified".
  5. Triage likely analyzer false positives before elevating them into blockers.
  6. If a required step could not be done, state it as a review gap, not as silent omission.
Treat this as the minimum bar. Analyzer JSON alone is not the final review.
当用户要求进行设计审查完整报告可制板评估或类似需求时,不得仅运行一两个分析器并汇总结果就结束。本技能中的设计审查需遵循更严格的规范:
  1. 阅读本
    SKILL.md
    中的完整工作流程,而非仅分析器命令部分。
  2. 撰写报告前阅读
    references/report-generation.md
  3. 针对项目中存在的所有文件类型运行适用的分析器,并明确说明已运行和未运行的分析器。
  4. 在声称任何内容“已验证”前,进行原始文件与数据手册的交叉验证。
  5. 在将分析器的疑似误报升级为阻塞问题前,先进行分类排查。
  6. 若某个必要步骤无法完成,需在报告中说明为审查缺口,而非静默省略。
以此为最低标准。仅分析器JSON输出不能作为最终审查结果。

Minimum Review Checklist

最低审查清单

For a full design review, explicitly account for each item below in the report:
  • datasheets/
    present, synced, or verification gap stated
  • analyze_schematic.py
  • analyze_pcb.py --full
  • cross_analysis.py
  • analyze_emc.py
  • SPICE simulation when any simulator is installed
  • analyze_thermal.py
    when both schematic and PCB JSON exist
  • analyze_gerbers.py
    when fabrication outputs exist
  • lifecycle audit when network access and MPN coverage allow it
  • prior review / prior run delta check
  • raw schematic/PCB spot-verification elevated to full verification for critical parts
  • explicit report sections for blockers, verification basis, false positives, and skipped analyses
If an item is not applicable, say why. If it was skipped, say why. If it failed, say how that limits confidence.
对于完整设计审查,需在报告中明确覆盖以下每一项:
  • datasheets/
    是否存在、已同步,或已说明验证缺口
  • analyze_schematic.py
  • analyze_pcb.py --full
  • cross_analysis.py
  • analyze_emc.py
  • 若安装了任何仿真器,需进行SPICE仿真
  • 若同时存在原理图和PCB JSON,需运行
    analyze_thermal.py
  • 若存在制造输出文件,需运行
    analyze_gerbers.py
  • 若有网络访问权限且MPN覆盖完整,需进行生命周期审计
  • 与之前审查/运行结果的差异检查
  • 对关键元器件将原始原理图/PCB的抽查升级为完整验证
  • 报告中需包含阻塞问题、验证依据、误报和跳过分析的明确章节
若某项不适用,需说明原因;若被跳过,需说明理由;若失败,需说明其对置信度的影响。

Common Review Failure Modes

常见审查失败模式

These are the failure modes this contract is meant to prevent:
  • Stopping after schematic + PCB + EMC output and calling it a complete review
  • Reporting analyzer findings without checking whether they are expected layout artifacts
  • Claiming "verified" without direct datasheet evidence or structured extraction evidence
  • Omitting thermal, lifecycle, prior-review delta, or gerber checks without disclosure
  • Writing a report that lacks a verdict, blockers table, verification basis, or skipped-analysis notes
  • Reading only the first part of this skill and missing the design-review workflow later in the file
本规范旨在预防以下失败模式:
  • 仅运行原理图+PCB+EMC分析就声称完成审查
  • 直接报告分析器结果而不检查是否为预期的布局 artifacts
  • 在无数据手册证据或结构化提取证据的情况下声称“已验证”
  • 未披露就省略热分析、生命周期分析、历史审查差异或Gerber检查
  • 撰写的报告缺少结论、阻塞问题表、验证依据或跳过分析的说明
  • 仅阅读本技能的前半部分,忽略文件后半部分的设计审查工作流程

PDF Schematic Analysis

PDF原理图分析

This skill also handles PDF schematics — reference designs, dev board schematics, eval board docs, application notes, and datasheet typical-application circuits. Common use cases:
  • Analyze a manufacturer's reference design to understand the circuit
  • Extract a subcircuit (power supply, USB interface, sensor front-end) to incorporate into your own KiCad design
  • Compare a PDF reference design against your own schematic
  • Extract a full BOM from a PDF schematic
  • Validate component values in a PDF against current datasheets
Workflow: Read the PDF pages visually → identify components and connections → extract structured data → translate to KiCad symbols and nets → validate against datasheets.
For the full methodology — component extraction, notation conventions, net mapping, subcircuit extraction, KiCad translation, and validation — read
references/pdf-schematic-extraction.md
.
For deep validation of extracted circuits against datasheets (verifying values, checking patterns, detecting errors), use the methodology in
references/schematic-analysis.md
.
本技能还支持处理PDF原理图 — 包括参考设计、开发板原理图、评估板文档、应用笔记和数据手册中的典型应用电路。常见使用场景:
  • 分析厂商参考设计以理解电路原理
  • 提取子电路(电源、USB接口、传感器前端)并整合到自己的KiCad设计中
  • 将PDF参考设计与自己的原理图进行对比
  • 从PDF原理图中提取完整BOM
  • 验证PDF中的元器件值是否符合当前数据手册
工作流程: 可视化读取PDF页面 → 识别元器件和连接关系 → 提取结构化数据 → 转换为KiCad符号和网络 → 对照数据手册验证。
关于完整方法学 — 包括元器件提取、符号约定、网络映射、子电路提取、KiCad转换和验证,请阅读
references/pdf-schematic-extraction.md
如需针对提取的电路进行深度数据手册验证(验证参数、检查模式、检测错误),请使用
references/schematic-analysis.md
中的方法学。

Analysis Scripts

分析脚本

This skill includes Python scripts that extract comprehensive structured JSON from KiCad files in a single pass. Run these first, then reason about the output.
Read analyzer JSON output directly rather than writing ad-hoc extraction scripts. The JSON schema has specific field names (documented below and in
references/output-schema.md
) that are easy to get wrong in custom code. To extract a specific section:
python3 -c "import json; d=json.load(open('file.json')); print(json.dumps(d['key'], indent=2))"
.
When the JSON surprises you — an AttributeError, unexpected shape, field returning
None
that "should" have a value — stop and run
--schema
before writing a second extraction attempt. It prints the exact field names and types for every top-level key:
bash
python3 <skill-path>/scripts/analyze_schematic.py --schema
python3 <skill-path>/scripts/analyze_pcb.py --schema
python3 <skill-path>/scripts/analyze_gerbers.py --schema
JSON field cheat sheet — the most common mistakes when reading analyzer output by hand:
What you wantCorrect path and fieldCommon mistake
Pins on a net
nets[<name>].pins[].component / .pin_number / .pin_name / .pin_type
ref
,
pin
,
type
,
number
Unnamed-net pretty display
nets[<name>].display_name
— when set, a
Ref.PinName
hint for an
__unnamed_N
net whose only named IC pin tells the story (e.g.
__unnamed_36 → U1.VBOOT
). Absent means the analyzer couldn't disambiguate.
Ignoring
display_name
and pasting raw
__unnamed_36
into the report
IC pin map
ic_pin_analysis[]
is a list of IC entries; each has
.reference
and
.pins[]
with
.pin_number / .pin_name / .pin_type / .net / .connected_to[]
Treating it as
{ref: {...}}
or
pins[].number
Detected circuitsEvery pattern-matched circuit (power regulators, RC filters, crystal oscillators, bridges, …) lives in
findings[]
— filter with
finding_schema.get_findings(data, Det.POWER_REGULATORS)
etc. Do not read from
subcircuits[]
: that's an IC-neighborhood grouping (
{center_ic, ic_value, neighbor_components, …}
), not a categorized detection index
Looking for
subcircuits.power_regulators
,
subcircuits.rc_filters
, or any
subcircuits[type]
key — these never existed in v1.3 output
Zone net
pcb.zones[].net
is an integer net ID, not a string. Use
f"{net!r}"
or convert first
f"{net:20s}"
— crashes with
ValueError: Unknown format code 's' for object of type 'int'
Footprint position
pcb.footprints[].x / .y
at top level (no
.position
wrapper)
footprints[].position.x
Findings
findings[]
flat list — each has
rule_id
,
detector
,
severity
,
summary
,
report_context
. Filter with
finding_schema.get_findings(data, Det.*)
or
group_findings(data)
Looking for keyed dicts like
signal_analysis.power_regulators[]
(pre-v1.3 format, removed)
This prevents format-string bugs and wrong field names. Use f-strings or
json.dumps()
for output formatting — never
%s
with non-string types. See
references/output-schema.md
for the full schema with common extraction patterns.
In all commands below,
<skill-path>
refers to this skill's base directory (shown at the top of this file when loaded).
本技能包含Python脚本,可从KiCad文件中一次性提取全面的结构化JSON。请先运行这些脚本,再基于输出结果进行分析。
直接读取分析器JSON输出,而非编写临时提取脚本。JSON schema有特定的字段名(如下文和
references/output-schema.md
中所述),自定义代码很容易出错。如需提取特定部分:
python3 -c "import json; d=json.load(open('file.json')); print(json.dumps(d['key'], indent=2))"
当JSON输出出现异常 — 比如AttributeError、意外结构、本该有值却返回
None
— 请停止编写第二次提取尝试,先运行
--schema
。它会打印每个顶级键的准确字段名和类型:
bash
python3 <skill-path>/scripts/analyze_schematic.py --schema
python3 <skill-path>/scripts/analyze_pcb.py --schema
python3 <skill-path>/scripts/analyze_gerbers.py --schema
JSON字段速查表 — 手动读取分析器输出时最常见的错误:
需求正确路径和字段常见错误
网络上的引脚
nets[<name>].pins[].component / .pin_number / .pin_name / .pin_type
使用
ref
,
pin
,
type
,
number
无名网络的友好显示
nets[<name>].display_name
— 当设置后,会为
__unnamed_N
网络提供
Ref.PinName
提示(例如
__unnamed_36 → U1.VBOOT
)。若未设置,说明分析器无法区分该网络。
忽略
display_name
,直接在报告中使用原始的
__unnamed_36
IC引脚映射
ic_pin_analysis[]
是IC条目的列表;每个条目包含
.reference
.pins[]
,其中
.pins[]
包含
.pin_number / .pin_name / .pin_type / .net / .connected_to[]
将其视为
{ref: {...}}
pins[].number
检测到的电路所有模式匹配的电路(电源稳压器、RC滤波器、晶体振荡器、桥路等)都在
findings[]
中 — 使用
finding_schema.get_findings(data, Det.POWER_REGULATORS)
等方法筛选。请勿读取
subcircuits[]
:这是基于IC周边的分组(
{center_ic, ic_value, neighbor_components, …}
),而非分类检测索引
寻找
subcircuits.power_regulators
,
subcircuits.rc_filters
或任何
subcircuits[type]
键 — 这些在v1.3输出中从未存在
区域网络
pcb.zones[].net
整数网络ID,而非字符串。使用
f"{net!r}"
或先转换类型
使用
f"{net:20s}"
— 会触发
ValueError: Unknown format code 's' for object of type 'int'
错误
封装位置
pcb.footprints[].x / .y
位于顶层(无
.position
包装)
使用
footprints[].position.x
检测结果
findings[]
是扁平列表 — 每个条目包含
rule_id
,
detector
,
severity
,
summary
,
report_context
。使用
finding_schema.get_findings(data, Det.*)
group_findings(data)
筛选
寻找键值对形式的结构,如
signal_analysis.power_regulators[]
(v1.3之前的格式,已移除)
这能避免格式字符串错误和字段名误用。输出格式化请使用f-strings或
json.dumps()
— 切勿对非字符串类型使用
%s
。完整schema及常见提取模式请参考
references/output-schema.md
以下所有命令中,
<skill-path>
指本技能的根目录(加载本文件时顶部会显示)。

Schematic Analyzer

原理图分析器

bash
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/ --compact
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --output analysis.json  # one-off, no cache
Outputs structured JSON (~60-220KB depending on board complexity) with:
  • Components & BOM: inventory with reference, value, footprint, lib_id, type classification, MPN, datasheet; deduplicated BOM with quantities
  • Nets: full connectivity map with pin-to-net mapping, wire counts, no-connects
  • Detected subcircuits (pattern-matched circuits — all emitted as
    findings[]
    entries with matching
    Det.*
    detectors; use
    get_findings(data, Det.POWER_REGULATORS)
    etc. to fetch):
    • Power regulators — LDO/switching/inverting topology, Vout estimation via datasheet-verified Vref lookup (~60 families) with heuristic fallback and fixed-output suffix parsing,
      vref_source
      (
      lookup
      /
      heuristic
      /
      fixed_suffix
      ) and
      vout_net_mismatch
      fields
    • Voltage dividers, RC/LC filters (cutoff frequency), feedback networks, crystal circuits (load cap analysis, IC pin-based detection)
    • Op-amp circuits (configuration, gain, integrator/compensator), transistor circuits (net-name-aware load classification: motor/heater/fan/solenoid/valve/pump/relay/speaker/buzzer/lamp; FET level shifter topology)
    • Bridge circuits (H-bridge, 3-phase, cross-sheet detection), protection devices (ESD/TVS), current sense, decoupling analysis
    • Domain-specific: RF chains, RF matching networks, BMS, Ethernet (BFS PHY-to-connector tracing), HDMI/DVI interfaces, memory interfaces, key matrices (net-name and topology-based), isolation barriers, addressable LED chains (WS2812/SK6812/APA102), battery chargers (TP4056/MCP73831/BQ2404x), motor drivers (A4988/TMC2209/DRV8301), ESD protection coverage audit, debug interfaces (SWD/JTAG with MCU tracing), power path (load switches/ideal diodes/USB PD controllers), ADC signal conditioning (external ADCs + voltage references with anti-aliasing cross-ref), reset/supervisor circuits (voltage supervisors/watchdogs/RC reset networks), clock distribution (clock generators/PLLs/oscillator output tracing), display/touch interfaces (SSD1306/ILI9341/ST7789/FT6236/GT911), sensor fusion (IMU/environmental/magnetometer with interrupt validation and bus clustering), level shifters (IC-based + discrete BSS138 with supply domain mapping), audio circuits (amplifiers/codecs with I2S/class-D detection), LED driver ICs (PWM/matrix/constant-current), RTC circuits (battery backup/crystal pairing), LED lighting audit (current limiting validation), thermocouple/RTD interfaces (MAX31855/MAX31865), power sequencing validation (power tree/enable chain/PG daisy chain analysis)
  • IC pinout analysis: pin-level connectivity, IC function classification (3-tier: library prefix, part number keywords, description fallback)
  • Power analysis: PDN impedance (1kHz–1GHz with MLCC parasitics), power budget, power sequencing (EN/PG chains), sleep current audit (resistive paths + regulator Iq with EN detection), voltage derating, inrush estimation
  • Design analysis: ERC warnings, power domains, bus detection (I2C/SPI/UART/CAN/RS-485 with COPI/CIPO/SDI/SDO), differential pairs (suffix-pair matching for USB/LVDS/Ethernet/HDMI/MIPI/PCIe/SATA/CAN/RS-485), cross-domain signals (voltage equivalence), BOM optimization, test coverage, assembly complexity, USB compliance
  • Quality checks: annotation completeness, label validation, PWR_FLAG audit, footprint filter validation, sourcing audit, property pattern audit, generic transistor symbol detection (flags Q_NPN_/Q_PNP_/Q_NMOS_/Q_PMOS_ symbols with datasheet availability check)
  • Structural: MCU alternate pin summary, ground domain classification, bus topology, wire geometry, spatial clustering, pin coverage, hierarchical label validation
Supports modern
.kicad_sch
(KiCad 6+) and legacy
.sch
(KiCad 4/5). Hierarchical designs parsed recursively.
Legacy format: For KiCad 5 legacy
.sch
files, the analyzer parses
.lib
files (cache libraries and project libs) to populate pin data. Pin-to-net mapping, signal analysis, and subcircuit detection all work when
.lib
files are available. Coverage is typically 92–100% — components whose
.lib
files are missing (standard KiCad system libs not in the repo) will lack pin data. Built-in fallbacks cover 40+ common symbols (R, C, L, D, LED, transistors, MOSFETs, crystals, switches, polarized caps, connectors up to 20-pin, resistor packs) with mil-based pin offsets and automatic wire-snap correction for version-mismatched pin positions.
bash
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/ --compact
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --output analysis.json  # 一次性运行,不缓存
输出结构化JSON(大小取决于电路板复杂度,约60-220KB),包含:
  • 元器件与BOM:清单包含参考编号、参数、封装、lib_id、类型分类、MPN、数据手册;去重后的BOM包含数量
  • 网络:完整连接映射,包含引脚-网络映射、导线数量、无连接标记
  • 检测到的子电路(模式匹配电路 — 全部作为
    findings[]
    条目输出,带有匹配的
    Det.*
    检测器;使用
    get_findings(data, Det.POWER_REGULATORS)
    等方法获取):
    • 电源稳压器 — LDO/开关/逆变拓扑,通过数据手册验证的Vref查找(约60个系列)估算输出电压,同时提供启发式回退和固定输出后缀解析,包含
      vref_source
      lookup
      /
      heuristic
      /
      fixed_suffix
      )和
      vout_net_mismatch
      字段
    • 分压器、RC/LC滤波器(截止频率)、反馈网络、晶体电路(负载电容分析、基于IC引脚的检测)
    • 运算放大器电路(配置、增益、积分器/补偿器)、晶体管电路(基于网络名称的负载分类:电机/加热器/风扇/电磁阀/阀门/泵/继电器/扬声器/蜂鸣器/灯;FET电平转换器拓扑)
    • 桥路电路(H桥、三相、跨页检测)、保护器件(ESD/TVS)、电流检测、去耦分析
    • 特定领域:RF链路、RF匹配网络、BMS、以太网(BFS PHY到连接器追踪)、HDMI/DVI接口、内存接口、按键矩阵(基于网络名称和拓扑)、隔离屏障、可寻址LED链(WS2812/SK6812/APA102)、电池充电器(TP4056/MCP73831/BQ2404x)、电机驱动器(A4988/TMC2209/DRV8301)、ESD保护覆盖审计、调试接口(SWD/JTAG及MCU追踪)、电源路径(负载开关/理想二极管/USB PD控制器)、ADC信号调理(外部ADC+电压基准及抗混叠交叉验证)、复位/监控电路(电压监控器/看门狗/RC复位网络)、时钟分配(时钟发生器/PLL/振荡器输出追踪)、显示/触摸接口(SSD1306/ILI9341/ST7789/FT6236/GT911)、传感器融合(IMU/环境/磁力计及中断验证和总线聚类)、电平转换器(基于IC+分立BSS138及电源域映射)、音频电路(放大器/编解码器及I2S/D类检测)、LED驱动IC(PWM/矩阵/恒流)、RTC电路(电池备份/晶体配对)、LED照明审计(限流验证)、热电偶/RTD接口(MAX31855/MAX31865)、电源时序验证(电源树/使能链/PG菊花链分析)
  • IC引脚分析:引脚级连接、IC功能分类(三级:库前缀、型号关键词、描述回退)
  • 电源分析:PDN阻抗(1kHz–1GHz,含MLCC寄生参数)、电源预算、电源时序(EN/PG链)、休眠电流审计(电阻路径+带使能检测的稳压器静态电流)、电压降额、浪涌估算
  • 设计分析:ERC警告、电源域、总线检测(I2C/SPI/UART/CAN/RS-485及COPI/CIPO/SDI/SDO)、差分对(USB/LVDS/以太网/HDMI/MIPI/PCIe/SATA/CAN/RS-485的后缀配对)、跨域信号(电压等效性)、BOM优化、测试覆盖、组装复杂度、USB合规性
  • 质量检查:注释完整性、标签验证、PWR_FLAG审计、封装过滤器验证、采购审计、属性模式审计、通用晶体管符号检测(标记Q_NPN_/Q_PNP_/Q_NMOS_/Q_PMOS_符号,并检查数据手册可用性)
  • 结构:MCU备用引脚汇总、地域分类、总线拓扑、导线几何形状、空间聚类、引脚覆盖、层级标签验证
支持现代
.kicad_sch
(KiCad 6+)和旧版
.sch
(KiCad 4/5)。分层设计会递归解析。
旧版格式: 对于KiCad 5旧版
.sch
文件,分析器会解析
.lib
文件(缓存库和项目库)以填充引脚数据。当
.lib
文件可用时,引脚-网络映射、信号分析和子电路检测均可正常工作。覆盖率通常为92–100% — 若缺少
.lib
文件(仓库中没有标准KiCad系统库),对应的元器件会缺少引脚数据。内置回退机制覆盖40+常见符号(R、C、L、D、LED、晶体管、MOSFET、晶体、开关、极性电容、最多20引脚的连接器、电阻排),采用mil单位的引脚偏移,并自动修正版本不匹配导致的引脚位置导线对齐问题。

Supplementary Data for Legacy Designs

旧版设计的补充数据

When
analyze_schematic.py
returns incomplete data (components with missing pins due to unavailable
.lib
files), use additional project files to recover full analysis capability. The most valuable source is the
.net
netlist file, which provides explicit pin-to-net mapping that closes any remaining gaps.
For detailed parsing instructions, data recovery workflows, and a priority matrix of supplementary sources (netlist, cache library, PCB cross-reference, PDF exports), read
references/supplementary-data-sources.md
.
Verify analyzer output against reality. The analyzer can silently produce plausible-looking but incorrect results — wrong voltage estimates, missing MPNs, wrong pin-to-net mappings. These don't cause script errors; they just produce bad data that flows into your report. In testing across multiple boards, every project had at least one misleading analyzer output. Cross-reference against the raw
.kicad_sch
file:
  1. Component count — grep for
    (symbol (lib_id
    blocks, subtract power symbols. Must match analyzer count exactly.
  2. Pin-to-net mapping — verify the analyzer's pin-to-net mapping against the raw schematic for each component. Read the symbol block, trace wires/labels to confirm connections. Cross-reference IC pin assignments against the manufacturer's datasheet pin table. This is the highest-value verification step — a wrong pin mapping produces a non-functional board and is invisible to DRC/ERC.
  3. Physical correctness (not just consistency) — consistency checks (schematic=PCB=analyzer all agree) are necessary but not sufficient. They only confirm the design is internally coherent — not that it matches the real-world part. The most dangerous case: a transistor symbol encodes a pinout assumption (like
    Q_NPN_BEC
    = pin 1=B, 2=E, 3=C) that doesn't match the actual part. Everything passes consistency checks, but the board is wrong. To catch this:
    • For transistors (BJT/MOSFET) in SOT-23, SOT-223, TO-252 and similar packages, the KiCad
      lib_id
      suffix encodes a pin ordering assumption. SOT-23 BJTs exist in at least 6 pinout variants (BEC, BCE, EBC, ECB, CBE, CEB); SOT-23 MOSFETs in GDS, GSD, SGD, DSG. If no MPN is specified, there's no way to verify the assumption — flag this as a critical ambiguity.
    • When an MPN is specified, verify the symbol's pin-to-pad assignment against the datasheet's pinout diagram for that specific package.
    • This principle extends beyond transistors — any component where multiple pin orderings exist for the same package (voltage regulators with different pin assignments, connectors with vendor-specific pinouts) needs MPN-level verification.
    • When verification isn't possible, assess plausibility. Not all unverified choices carry equal risk. Some align with strong conventions (the most common SOT-23 NPN pinout is BCE; 2N2222 in SOT-23 is almost always BCE); others go against convention or are genuinely ambiguous (SOT-23 MOSFETs have no dominant standard). When an MPN is missing and you can't verify, use domain knowledge — typical pinouts for that device type and package, manufacturer conventions, what the majority of parts in that category do — to assess whether the assumed pinout is likely correct, unusual, or a coin flip. Report the confidence level: "matches the most common convention" is different from "could go either way." This same reasoning applies to passive values (is 4.7kΩ a typical pull-up value for this bus?), circuit topologies (is this a standard application circuit?), and component selection (is this part commonly used for this purpose?).
  4. Net trace — trace power rails and critical signal nets end-to-end through wires/labels. Verify the analyzer's pin list is complete for each net.
  5. Regulator Vout — check the
    vref_source
    field.
    "lookup"
    means datasheet-verified (~60 families);
    "heuristic"
    means it's a guess that needs manual verification. The
    vout_net_mismatch
    field flags estimated Vout differing >15% from the output rail name voltage.
  6. Hierarchical connectivity — on multi-sheet designs, verify sub-sheet connections are reflected in the net data.
See
references/schematic-analysis.md
Step 2 for the full verification checklist. If the script fails or returns unexpected results, see
references/manual-schematic-parsing.md
for the complete fallback methodology.
analyze_schematic.py
返回不完整数据(因
.lib
文件缺失导致元器件引脚缺失)时,可使用其他项目文件恢复完整分析能力。最有价值的来源是
.net
网表文件,它提供明确的引脚-网络映射,可填补剩余缺口。
详细解析说明、数据恢复工作流程及补充来源优先级矩阵(网表、缓存库、PCB交叉参考、PDF导出)请阅读
references/supplementary-data-sources.md
验证分析器输出与实际情况是否一致。 分析器可能会静默生成看似合理但错误的结果 — 错误的电压估算、缺失的MPN、错误的引脚-网络映射。这些不会导致脚本错误,但会生成错误数据并流入报告。在多个电路板的测试中,每个项目至少存在一处误导性分析器输出。需对照原始
.kicad_sch
文件进行交叉验证:
  1. 元器件数量 — 搜索
    (symbol (lib_id
    块,减去电源符号。必须与分析器统计的数量完全一致。
  2. 引脚-网络映射 — 针对每个元器件,验证分析器的引脚-网络映射与原始原理图是否一致。读取符号块,追踪导线/标签以确认连接关系。对照厂商数据手册的引脚表验证IC引脚分配。这是价值最高的验证步骤 — 错误的引脚映射会导致电路板无法工作,且无法被DRC/ERC检测到。
  3. 物理正确性(而非仅一致性) — 一致性检查(原理图=PCB=分析器结果一致)是必要但不充分的。它仅能确认设计内部连贯 — 无法确认是否与实际元器件匹配。最危险的情况:晶体管符号编码了引脚假设(如
    Q_NPN_BEC
    = 引脚1=B,2=E,3=C),但与实际元器件不符。所有一致性检查都通过,但电路板无法正常工作。为避免这种情况:
    • 对于SOT-23、SOT-223、TO-252等封装的晶体管(BJT/MOSFET),KiCad
      lib_id
      后缀编码了引脚顺序假设。SOT-23 BJT至少有6种引脚变体(BEC、BCE、EBC、ECB、CBE、CEB);SOT-23 MOSFET有GDS、GSD、SGD、DSG等变体。若未指定MPN,则无法验证该假设 — 需将其标记为关键歧义点。
    • 若指定了MPN,需对照该封装的数据手册引脚图验证符号的引脚-焊盘分配。
    • 此原则适用于所有元器件 — 同一封装存在多种引脚顺序的元器件(引脚分配不同的电压稳压器、厂商特定引脚的连接器)都需要基于MPN的验证。
    • 当无法验证时,评估合理性。 并非所有未验证的选择都有相同风险。有些符合通用惯例(最常见的SOT-23 NPN引脚顺序是BCE;SOT-23封装的2N2222几乎都是BCE);有些则违背惯例或存在歧义(SOT-23 MOSFET没有主导标准)。当缺少MPN且无法验证时,使用领域知识 — 该器件类型和封装的典型引脚顺序、厂商惯例、该类别中大多数元器件的做法 — 评估假设的引脚顺序是否可能正确、不常见或完全不确定。报告置信度等级:“符合最常见惯例”与“两种可能性都存在”是不同的。此推理也适用于无源器件参数(该总线的典型上拉电阻是4.7kΩ吗?)、电路拓扑(这是标准应用电路吗?)和元器件选型(该元器件是否常用于此场景?)。
  4. 网络追踪 — 从头到尾追踪电源轨和关键信号网络的导线/标签。验证分析器的引脚列表是否覆盖每个网络的所有引脚。
  5. 稳压器输出电压 — 检查
    vref_source
    字段。
    "lookup"
    表示基于数据手册验证(约60个系列);
    "heuristic"
    表示推测值,需手动验证。
    vout_net_mismatch
    字段标记估算输出电压与输出轨名称电压差异>15%的情况。
  6. 分层连接 — 对于多页设计,验证子页连接是否在网络数据中正确体现。
完整验证清单请参考
references/schematic-analysis.md
第2步。若脚本失败或返回意外结果,请参考
references/manual-schematic-parsing.md
获取完整的备用方法。

PCB Layout Analyzer

PCB布局分析器

bash
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/ --proximity  # add crosstalk analysis
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --output pcb.json  # one-off, no cache
Outputs structured JSON (~50-300KB depending on board complexity) with:
  • Core: footprint inventory (pads, courtyards, net assignments, extended attrs, schematic cross-reference), track/via statistics, zone summaries, board outline/dimensions, routing completeness
  • Zones & copper presence: zone outline vs filled polygon bounding boxes, fill ratio, cross-layer copper presence at every pad (which components have zone copper on the opposite layer and which don't), same-layer foreign zone detection
  • Via analysis: type breakdown (through/blind/micro), annular ring checks, via-in-pad detection, BGA/QFN fanout patterns, current capacity, stitching via identification, tenting
  • Signal integrity: per-net trace length, layer transition tracking (ground return paths), trace proximity/crosstalk (with
    --proximity
    )
  • Power & thermal: current capacity per net, power net routing summary, ground domain identification (AGND/DGND), zone stitching via density, thermal pad detection and via counting
  • Manufacturing: placement analysis (courtyard overlaps, edge clearance), decoupling cap distances, DFM scoring (JLCPCB standard/advanced tier), tombstoning risk (0201/0402 thermal asymmetry), thermal pad via adequacy, silkscreen documentation audit
Add
--full
to include individual track/via coordinates, per-segment trace impedance (microstrip Z0 from stackup), pad-to-pad routed distances, return path continuity analysis, and via stub lengths. The
--full
output feeds the
spice
skill's parasitic extraction (
extract_parasitics.py
) for PCB-aware simulation. Supports KiCad 5 legacy format.
Zone fills must be current. The copper presence analysis uses KiCad's filled polygon data, which is computed when the user runs Edit → Fill All Zones (shortcut
B
) and stored in the
.kicad_pcb
file. If the board was modified after the last fill, the filled polygon data may be stale and the copper presence results will be inaccurate. When reviewing copper presence data, note whether the
fill_ratio
seems reasonable — a zone with 0 filled area or
is_filled: false
likely hasn't been filled.
Zone outline ≠ actual copper. The zone
outline_bbox
is the user-drawn boundary;
filled_bbox
is where copper actually exists after clearances, keepouts, and priority cuts. The
copper_presence
section shows which components have zone copper on the opposite layer — use this for capacitive touch pad isolation, antenna keep-out, and thermal analysis instead of inferring copper presence from zone outlines.
Copper-sensitive components need deeper checks. For capacitive touch pads and antennas, confirming "no opposite-layer copper" is necessary but not sufficient. The copper absence could be accidental — one zone refill after a routing change could add copper and kill touch sensitivity or detune the antenna. Check for explicit keepout zones (rule areas) that enforce the copper-free area as a DRC rule. Also measure same-layer GND clearance around touch pads and compare against the controller's app note minimum. For touch pads, compare trace lengths across all pads — significant asymmetry shifts baseline readings per channel. Report physical details (pad size, position, clearance, trace width/length) for all copper-sensitive components. See
references/pcb-layout-analysis.md
→ Copper-Sensitive Components for the full checklist.
Verify after every run: Confirm footprint count and board outline dimensions against the raw
.kicad_pcb
file. Verify pad-to-net assignments for IC footprints against the schematic's pin-to-net mapping — this catches library footprint errors where pad numbering doesn't match the symbol pinout. If the script fails, see
references/manual-pcb-parsing.md
for the fallback methodology.
bash
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/ --proximity  # 添加串扰分析
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --output pcb.json  # 一次性运行,不缓存
输出结构化JSON(大小取决于电路板复杂度,约50-300KB),包含:
  • 核心内容:封装清单(焊盘、禁布区、网络分配、扩展属性、原理图交叉参考)、走线/过孔统计、区域汇总、电路板轮廓/尺寸、布线完整性
  • 区域与覆铜情况:区域轮廓与填充多边形边界框、填充率、每个焊盘的跨层覆铜情况(哪些元器件在对面层有区域覆铜,哪些没有)、同层异区域检测
  • 过孔分析:类型细分(通孔/盲孔/微孔)、焊环检查、过孔入焊盘检测、BGA/QFN扇出模式、载流能力、缝合过孔识别、阻焊覆盖
  • 信号完整性:每个网络的走线长度、层转换追踪(地返回路径)、走线间距/串扰(需添加
    --proximity
  • 电源与热分析:每个网络的载流能力、电源网络布线汇总、地域识别(AGND/DGND)、区域缝合过孔密度、热焊盘检测与过孔计数
  • 制造相关:布局分析(禁布区重叠、边缘间距)、去耦电容距离、DFM评分(JLCPCB标准/高级等级)、立碑风险(0201/0402热不对称)、热焊盘过孔充足性、丝印文档审计
添加
--full
参数可包含单个走线/过孔坐标、每段走线阻抗(基于叠层的微带线Z0)、焊盘到焊盘的布线距离、返回路径连续性分析和过孔 stub长度。
--full
输出可提供给
spice
技能进行寄生参数提取(
extract_parasitics.py
),用于PCB感知的仿真。支持KiCad 5旧版格式。
区域填充必须是最新的。 覆铜情况分析使用KiCad的填充多边形数据,该数据在用户运行Edit → Fill All Zones(快捷键
B
)时计算并存储在
.kicad_pcb
文件中。若上次填充后修改了电路板,填充多边形数据可能过时,导致覆铜情况结果不准确。审查覆铜数据时,需注意
fill_ratio
是否合理 — 填充面积为0或
is_filled: false
的区域可能未进行填充。
区域轮廓≠实际覆铜。 区域的
outline_bbox
是用户绘制的边界;
filled_bbox
是考虑间距、禁布区和优先级切割后实际存在覆铜的区域。
copper_presence
部分显示哪些元器件在对面层有区域覆铜 — 用于电容触摸焊盘隔离、天线禁布区和热分析,而非通过区域轮廓推断覆铜情况。
对覆铜敏感的元器件需要更深入的检查。 对于电容触摸焊盘和天线,确认“对面层无覆铜”是必要但不充分的。覆铜缺失可能是意外 — 布线修改后的一次区域填充可能会添加覆铜,导致触摸灵敏度下降或天线失谐。需检查是否存在明确的禁布区(规则区域),将无覆铜区域作为DRC规则强制执行。同时测量触摸焊盘周围的同层GND间距,并与控制器应用笔记中的最小值对比。对于触摸焊盘,对比所有焊盘的走线长度 — 显著的不对称会导致各通道基线读数偏移。报告所有对覆铜敏感的元器件的物理细节(焊盘尺寸、位置、间距、走线宽度/长度)。完整清单请参考
references/pcb-layout-analysis.md
→ 对覆铜敏感的元器件。
每次运行后验证: 确认封装数量和电路板轮廓尺寸与原始
.kicad_pcb
文件一致。验证IC封装的焊盘-网络分配与原理图的引脚-网络映射是否一致 — 这能发现库封装焊盘编号与符号引脚不匹配的错误。若脚本失败,请参考
references/manual-pcb-parsing.md
获取备用方法。

PCB Rich Format and Assembly Checks

PCB富格式与组装检查

All PCB analysis sections now produce findings with the rich format (detector, rule_id, category, severity, confidence, summary, recommendation, report_context). Additionally, 7 new assembly/DFM checks run automatically:
  • FD-001: Fiducial marker presence (>= 3 per SMD side)
  • TE-001: Test point coverage across signal nets
  • OR-001: Passive component orientation consistency
  • SK-001: Silkscreen text overlapping exposed pads
  • VP-001: Via-in-pad without tenting (--full mode)
  • BV-001: Via clearance from board edges (--full mode)
  • KO-001: Keepout zone violations
  • CP-001: Same-layer foreign zone under a component. Severity is
    warning
    when the foreign zone is a non-ground net or the component has no GND pad; severity is
    info
    when the foreign zone is GND and the component has a GND pad (the common case of a bypass cap sitting over the ground pour — expected layout, not a clearance issue).
所有PCB分析部分现在都会生成富格式检测结果(检测器、rule_id、类别、严重程度、置信度、摘要、建议、report_context)。此外,会自动运行7项新的组装/DFM检查:
  • FD-001:基准标记存在情况(每面SMD至少3个)
  • TE-001:信号网络的测试点覆盖
  • OR-001:无源元器件方向一致性
  • SK-001:丝印文本与裸露焊盘重叠
  • VP-001:未阻焊覆盖的过孔入焊盘(--full模式)
  • BV-001:过孔与电路板边缘的间距(--full模式)
  • KO-001:禁布区违规
  • CP-001:元器件下方的同层异区域。当异区域为非地网络或元器件无GND焊盘时,严重程度为
    warning
    ;当异区域为GND且元器件有GND焊盘时(旁路电容位于地敷铜上方的常见布局,属于预期情况,而非间距问题),严重程度为
    info

Cross-Domain Analysis

跨域分析

After running both schematic and PCB analyzers, run the cross-domain analyzer. Point
--schematic
and
--pcb
at the current run's JSON files and pass
--analysis-dir analysis/
so the result lands inside the same run folder and the manifest tracks it:
undefined
运行完原理图和PCB分析器后,运行跨域分析器。将
--schematic
--pcb
指向当前运行的JSON文件,并传入
--analysis-dir analysis/
,使结果存入同一运行文件夹,便于清单追踪:
undefined

Recommended: integrate into the current run

推荐:整合到当前运行中

python3 <skill-path>/scripts/cross_analysis.py
--schematic analysis/<run_id>/schematic.json
--pcb analysis/<run_id>/pcb.json
--analysis-dir analysis/
python3 <skill-path>/scripts/cross_analysis.py
--schematic analysis/<run_id>/schematic.json
--pcb analysis/<run_id>/pcb.json
--analysis-dir analysis/

One-off (bypasses the cache)

一次性运行(绕过缓存)

python3 <skill-path>/scripts/cross_analysis.py
--schematic schematic.json --pcb pcb.json --output cross.json

Checks: CC-001 connector current capacity, EG-001 ESD protection gaps, DA-001 decoupling adequacy, XV-001..003 schematic/PCB sync. PCB JSON optional.
python3 <skill-path>/scripts/cross_analysis.py
--schematic schematic.json --pcb pcb.json --output cross.json

检查项:CC-001连接器载流能力、EG-001 ESD保护缺口、DA-001去耦充足性、XV-001..003原理图/PCB同步。PCB JSON为可选参数。

Connectivity Graph (--full mode)

连接图(--full模式)

When
--full
is used with the PCB analyzer, the output includes a
connectivity_graph
section with per-net copper connectivity analysis via union-find over pads, tracks, vias, and zone fills. This enables deterministic plane split detection and return path validation in cross_analysis.py. Each net entry shows island count, component-to-island mapping, gap locations, and disconnected pad pairs.
当PCB分析器使用
--full
参数时,输出包含
connectivity_graph
部分,通过焊盘、走线、过孔和区域填充的并查集进行每个网络的覆铜连接分析。这能在cross_analysis.py中实现确定性的平面分割检测和返回路径验证。每个网络条目显示孤岛数量、元器件-孤岛映射、缺口位置和断开的焊盘对。

Gerber & Drill Analyzer

Gerber与钻孔分析器

bash
undefined
bash
undefined

Recommended: integrate into the current run

推荐:整合到当前运行中

python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --analysis-dir analysis/

One-off

一次性运行

python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --output gerber.json
Outputs: layer identification (X2 attributes), component/net/pin mapping (KiCad 6+ TO attributes), aperture function classification, trace width distribution, board dimensions, drill classification (via/component/mounting), layer completeness, alignment verification, pad type summary (SMD/THT ratio). Add `--full` for complete pin-to-net connectivity dump. ~10KB JSON.

The gerber analyzer produces a `findings` list with rich format findings: GR-001 missing layers, GR-002 alignment issues, GR-003 drill problems, GR-004 paste aperture mismatches, GR-005 open board outlines.

If the script fails or returns unexpected results, see `references/manual-gerber-parsing.md` for the complete fallback methodology for parsing raw Gerber/Excellon files directly.

All scripts output JSON to stdout by default. Prefer `--analysis-dir analysis/`
to integrate output into the run-folder convention described in "Analysis
Cache Convention" below — every analyzer in a single session then co-locates
inside the same `analysis/<run_id>/` folder and is tracked by the manifest.
Use `--output file.json` only for one-off runs where you don't want the
result cached. Add `--compact` for single-line JSON.

**Analyzer JSON is worth keeping** — these are expensive to regenerate (large
schematics take time). `--analysis-dir` preserves every run and is the form
downstream tools (kidoc, diff_analysis, what_if) expect. They're not worth
committing to git, but don't delete them between analysis steps.
python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --output gerber.json
输出内容:层识别(X2属性)、元器件/网络/引脚映射(KiCad 6+ TO属性)、光圈功能分类、走线宽度分布、电路板尺寸、钻孔分类(过孔/元器件/安装孔)、层完整性、对齐验证、焊盘类型汇总(SMD/THT比例)。添加`--full`参数可获取完整的引脚-网络连接转储。JSON大小约10KB。

Gerber分析器生成`findings`列表,包含富格式检测结果:GR-001缺失层、GR-002对齐问题、GR-003钻孔问题、GR-004钢网光圈不匹配、GR-005电路板轮廓未闭合。

若脚本失败或返回意外结果,请参考`references/manual-gerber-parsing.md`获取直接解析原始Gerber/Excellon文件的完整备用方法。

所有脚本默认将JSON输出到标准输出。优先使用`--analysis-dir analysis/`将输出整合到“分析缓存规范”中描述的运行文件夹约定中 — 单次会话中的所有分析器结果会共存于同一`analysis/<run_id>/`文件夹,并由清单追踪。仅在不需要缓存结果的一次性运行中使用`--output file.json`。添加`--compact`参数可输出单行JSON。

**分析器JSON值得保留** — 重新生成成本较高(大型原理图需要较长时间)。`--analysis-dir`会保留每次运行的结果,这也是下游工具(kidoc、diff_analysis、what_if)期望的格式。无需提交到git,但不要在分析步骤之间删除它们。

Harmonized Output Format

统一输出格式

All analyzers produce a uniform output envelope:
json
{
    "analyzer_type": "schematic|pcb|emc|cross_analysis|thermal|gerber|lifecycle|spice",
    "schema_version": "1.3.0",
    "summary": {
        "total_findings": 42,
        "by_severity": {"error": 3, "warning": 15, "info": 24}
    },
    "findings": [
        {"rule_id": "...", "detector": "...", "severity": "...", "confidence": "...", "evidence_source": "...", "summary": "...", ...}
    ],
    "trust_summary": {
        "total_findings": 42,
        "trust_level": "high|mixed|low",
        "by_confidence": {"deterministic": 20, "heuristic": 18, "datasheet-backed": 4},
        "by_evidence_source": {"datasheet": 4, "topology": 10, "heuristic_rule": 18, ...},
        "provenance_coverage_pct": 96.5
    }
}
The
findings
list is the single authoritative source for all findings. Use
finding_schema.get_findings()
or
finding_schema.group_findings()
to filter by detector, rule prefix, or category. Detector names are available as constants in
finding_schema.Det
. Severities are
error
,
warning
, or
info
; confidence is
deterministic
,
heuristic
, or
datasheet-backed
.
All analyzers support
--text
for human-readable output,
--analysis-dir
for integrated run-folder output (preferred), and
--output
for writing to a specific file verbatim (one-off). When both are passed, the explicit
--output
path wins — pick one form per invocation.
所有分析器生成统一的输出结构:
json
{
    "analyzer_type": "schematic|pcb|emc|cross_analysis|thermal|gerber|lifecycle|spice",
    "schema_version": "1.3.0",
    "summary": {
        "total_findings": 42,
        "by_severity": {"error": 3, "warning": 15, "info": 24}
    },
    "findings": [
        {"rule_id": "...", "detector": "...", "severity": "...", "confidence": "...", "evidence_source": "...", "summary": "...", ...}
    ],
    "trust_summary": {
        "total_findings": 42,
        "trust_level": "high|mixed|low",
        "by_confidence": {"deterministic": 20, "heuristic": 18, "datasheet-backed": 4},
        "by_evidence_source": {"datasheet": 4, "topology": 10, "heuristic_rule": 18, ...},
        "provenance_coverage_pct": 96.5
    }
}
findings
列表是所有检测结果的唯一权威来源。使用
finding_schema.get_findings()
finding_schema.group_findings()
按检测器、规则前缀或类别筛选。检测器名称作为常量存在于
finding_schema.Det
中。严重程度分为
error
warning
info
;置信度分为
deterministic
heuristic
datasheet-backed
所有分析器支持
--text
参数输出人类可读内容,
--analysis-dir
参数用于整合到运行文件夹输出(推荐),
--output
参数用于直接写入指定文件(一次性运行)。若同时传入两个参数,显式的
--output
路径优先 — 每次调用仅选择一种形式。

Stage and Audience Filtering

阶段与受众筛选

All analyzers support
--stage
and
--audience
flags:
Stages:
schematic
,
layout
,
pre_fab
,
bring_up
Audiences:
designer
(default),
reviewer
,
manager
bash
undefined
所有分析器支持
--stage
--audience
参数:
阶段:
schematic
,
layout
,
pre_fab
,
bring_up
受众:
designer
(默认),
reviewer
,
manager
bash
undefined

Show only layout-relevant findings for a reviewer

仅向审查者显示与布局相关的检测结果

python3 <skill-path>/scripts/analyze_pcb.py board.kicad_pcb --stage layout --audience reviewer --text
python3 <skill-path>/scripts/analyze_pcb.py board.kicad_pcb --stage layout --audience reviewer --text

Manager summary of schematic review readiness

向管理者展示原理图审查就绪情况的摘要

python3 <skill-path>/scripts/analyze_schematic.py design.kicad_sch --audience manager --text
python3 <skill-path>/scripts/analyze_schematic.py design.kicad_sch --audience manager --text

Pre-fab checklist for cross-domain analysis

跨域分析的制板前检查清单

python3 <skill-path>/scripts/cross_analysis.py -s sch.json -p pcb.json --stage pre_fab --text

JSON output always includes all findings. `--stage` adds `stages` and `in_active_stage` fields to each finding plus a `stage_filter` summary. `audience_summary` is always computed with designer/reviewer/manager views. `--text` output respects both flags.
python3 <skill-path>/scripts/cross_analysis.py -s sch.json -p pcb.json --stage pre_fab --text

JSON输出始终包含所有检测结果。`--stage`参数会为每个检测结果添加`stages`和`in_active_stage`字段,并生成`stage_filter`摘要。`audience_summary`始终会计算设计师/审查者/管理者视角的内容。`--text`输出会同时遵循两个参数的筛选规则。

Generated Files

生成的文件

Analysis outputs are stored in
analysis/
with timestamped run folders managed by
analysis_cache.py
. The manifest (
analysis/manifest.json
) tracks all runs.
File TypeLocationRegenerable?Commit to git?
Analyzer JSON
analysis/<timestamp>/*.json
Yes (expensive)Configured by
track_in_git
in
.kicad-happy.json
(default: no)
Manifest
analysis/manifest.json
YesAlways (tracked by default)
Design review reportUser-chosen pathYesOptional
When creating design reviews, check the manifest for prior runs. If
auto_diff
is enabled and prior runs exist, automatically diff current vs previous using
diff_analysis.py
and include the delta in the "Previous Review Delta" section.
See also the
bom
skill's cleanup section for datasheets, order CSVs, and backups.
分析输出存储在
analysis/
目录中,由
analysis_cache.py
管理带时间戳的运行文件夹。清单文件(
analysis/manifest.json
)追踪所有运行记录。
文件类型位置可重新生成?是否提交到git?
分析器JSON
analysis/<timestamp>/*.json
是(成本较高)
.kicad-happy.json
中的
track_in_git
配置(默认:否)
清单
analysis/manifest.json
始终提交(默认追踪)
设计审查报告用户指定路径可选
创建设计审查时,检查清单中的历史运行记录。若
auto_diff
已启用且存在历史运行记录,自动使用
diff_analysis.py
对比当前与之前的结果,并将差异包含在“历史审查差异”章节中。
另请参考
bom
技能中关于数据手册、采购CSV和备份的清理章节。

Analysis Cache Configuration

分析缓存配置

The
analysis
section in
.kicad-happy.json
controls the shared analysis output directory:
json
{
  "analysis": {
    "output_dir": "analysis",
    "retention": 5,
    "auto_diff": true,
    "track_in_git": false,
    "diff_threshold": "major"
  }
}
FieldDefaultDescription
output_dir
"analysis"
Analysis directory path, relative to project root
retention
5
Max unpinned runs to keep.
0
= unlimited
auto_diff
true
Auto-include delta section in design reviews
track_in_git
false
When false, JSONs gitignored but manifest tracked
diff_threshold
"major"
Severity that triggers new timestamped folder:
minor
,
major
,
breaking
All fields are optional. Missing fields use defaults.
.kicad-happy.json
中的
analysis
部分控制共享分析输出目录:
json
{
  "analysis": {
    "output_dir": "analysis",
    "retention": 5,
    "auto_diff": true,
    "track_in_git": false,
    "diff_threshold": "major"
  }
}
字段默认值描述
output_dir
"analysis"
分析目录路径,相对于项目根目录
retention
5
保留的未固定运行记录的最大数量。
0
= 无限制
auto_diff
true
在设计审查中自动包含差异章节
track_in_git
false
为false时,JSON文件会被git忽略,但清单会被追踪
diff_threshold
"major"
触发新时间戳文件夹的严重程度:
minor
,
major
,
breaking
所有字段均为可选。缺失字段使用默认值。

Output JSON Schema Quick Reference

输出JSON Schema快速参考

Schematic analyzer top-level keys:
analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, title_block, statistics,
bom, components, nets, subcircuits, ic_pin_analysis, design_analysis,
connectivity_issues, hierarchy_context, hierarchy_warning,
net_classifications, rail_voltages
Optional (present when non-empty):
pdn_impedance
,
sleep_current_audit
,
voltage_derating
,
power_budget
,
power_sequencing
,
bom_optimization
,
test_coverage
,
assembly_complexity
,
usb_compliance
,
inrush_analysis
,
sheets
(multi-sheet only),
missing_info
,
bom_lock
,
project_settings
Key nested structures:
  • statistics
    :
    {total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}
  • bom[]
    :
    {reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}
  • components[]
    :
    {reference, value, footprint, lib_id, lib_name, type, category, mpn, datasheet, dnp, in_bom, parsed_value, ...}
  • nets{net_name}
    :
    {pins[], wires, labels[], ...}
    — each pin:
    {component, pin_number, pin_name, pin_type, ...}
    (NOT
    ref
    or
    pin
    )
  • subcircuits[]
    : IC-neighborhood groupings (
    {center_ic, ic_value, neighbor_components, ...}
    ), NOT a categorized detection index — see the JSON field cheat sheet at the top of this file.
  • Detected subcircuits live in
    findings[]
    — power regulators, voltage dividers, RC/LC filters, feedback networks, opamp/transistor/bridge/crystal circuits, current sense, decoupling, protection, buzzer/speaker, Ethernet/HDMI/memory interfaces, RF chains/matching, BMS, key matrices, isolation barriers, addressable LED chains, and design observations all emit as findings with matching
    Det.*
    detectors. Use
    get_findings(data, Det.POWER_REGULATORS)
    etc. to fetch them. The pre-v1.3
    signal_analysis
    wrapper and its top-level detection lists are gone.
PCB analyzer top-level keys:
analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, statistics, layers, setup,
nets, net_name_to_id, board_outline, component_groups, footprints,
tracks, vias, zones, keepout_zones, connectivity, net_lengths
Optional:
power_net_routing
,
decoupling_placement
,
ground_domains
,
layer_transitions
,
silkscreen
,
board_metadata
,
dimensions
,
groups
,
net_classes
,
dfm_summary
,
placement_density
,
copper_presence_summary
,
board_thickness_mm
,
trace_proximity
(with
--proximity
). Sections previously at top level (
thermal_analysis
,
thermal_pad_vias
,
tombstoning_risk
,
placement_analysis
,
current_capacity
,
copper_presence
,
dfm
) are now in
findings[]
. With
--full
, the output also includes a
connectivity_graph
section (see "Connectivity Graph" above).
Key nested structures:
  • net_lengths
    is a list (not dict):
    [{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...]
    sorted by length descending
  • power_net_routing
    is a list:
    [{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]
  • footprints[]
    :
    {reference, value, footprint, layer, pads[], sch_path, sch_sheetname, sch_sheetfile, connected_nets[], ...}
  • statistics
    :
    {footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}
Gerber analyzer top-level keys:
analyzer_type, schema_version, summary, findings, trust_summary,
directory, generator, layer_count, statistics, completeness, alignment,
drill_classification, pad_summary, board_dimensions, gerbers, drills
Workflow: When analyzing a KiCad project, scan the project directory for all available file types and run every applicable analyzer — not just the one the user mentioned. A complete analysis uses all the data available. Use
--analysis-dir analysis/
on all analyzers to share a single run folder tracked by the manifest. For one-off runs without cache tracking, use
--output file.json
instead.
Before starting the workflow below for a design review: read
references/report-generation.md
. The report structure, verification basis rules, skipped-analysis disclosure, and false-positive triage expectations there are part of the review workflow, not optional polish added at the end.
  1. Scan the project directory for
    .kicad_sch
    ,
    .kicad_pcb
    ,
    .kicad_pro
    , gerber directories, and
    .net
    /
    .xml
    netlist files.
  2. Sync datasheets (see Datasheet Acquisition below) — this is a prerequisite for verification, not optional. Without datasheets, all subsequent verification is reduced to internal consistency checks — confirming the design agrees with itself, not that it's correct. Run the sync before reading any analyzer output. If sync fails or no API keys are available, use fallback methods (Datasheet property URLs, individual downloads via
    digikey
    skill, ask the user). If critical IC datasheets can't be obtained, note this prominently in the report as a verification gap.
  3. Run the core analyzers. If the schematic exists, run
    analyze_schematic.py
    . If the PCB exists, run
    analyze_pcb.py --full
    . If gerbers exist, run
    analyze_gerbers.py
    . Run them in parallel when possible.
  4. Run cross-domain analysis — when both schematic and PCB analysis exist, run
    cross_analysis.py --schematic sch.json --pcb pcb.json
    . This catches dangerous cross-domain bugs (connector current vs trace width, ESD gaps, decoupling adequacy, schematic/PCB sync).
  5. Run EMC pre-compliance — when both schematic and PCB analysis exist, run
    analyze_emc.py --schematic sch.json --pcb pcb.json
    . This is required during design reviews, not optional. The EMC skill runs 44 rule checks covering ground plane integrity, decoupling, switching harmonics, PDN impedance, diff pair skew, ESD paths, and more. Include results in the EMC section of the report.
  6. Run SPICE simulation — first run
    which ngspice ltspice xyce
    . If any simulator is installed, SPICE is required before writing the report. Hand off to the
    spice
    skill with the schematic analysis JSON. This validates filter frequencies, divider ratios, opamp gains, and more against actual simulation results. SPICE takes <1 second on most boards and catches value-computation errors (wrong resistor ratio, wrong cap for cutoff frequency) that no static analyzer finds. If both schematic and PCB analysis exist, use
    --parasitics
    for high-impedance circuits (>100K feedback dividers, LC filters, RF matching networks). Include results in the Simulation Verification section of the report. Output schema: top-level keys are
    summary
    ,
    simulation_results
    ,
    workdir
    ,
    total_elapsed_s
    ,
    simulator
    . Each entry in
    simulation_results[]
    has:
    subcircuit_type
    ,
    components
    (list of refs, e.g.
    ["R5", "C3"]
    ),
    reference
    (joined refs, e.g.
    "R5/C3"
    ),
    status
    (
    pass
    /
    warn
    /
    fail
    /
    skip
    ),
    expected
    (dict of metric values),
    simulated
    (dict of measured values),
    delta
    (dict of error percentages).
  7. Run thermal analysis — when both schematic and PCB analysis exist, run
    analyze_thermal.py --schematic schematic.json --pcb pcb.json
    . Estimates junction temperatures from package θJA and board thermal via correction. Include results in the Thermal Hotspot section of the report.
  8. Run lifecycle audit (when network access and MPNs are available) — invoke via
    analyze_schematic.py --lifecycle
    flag. Checks component obsolescence status via distributor APIs. Include results in the Component Lifecycle section of the report, or note "Lifecycle audit not performed — [reason: no API keys / no network / no MPNs]."
  9. Read the
    .kicad_pro
    project file directly (it's JSON) for design rules, net classes, and DRC/ERC settings.
  10. Check for prior design reviews — scan the project directory for existing review files (
    *review*.md
    ,
    *design-review*.md
    ). If found, read the most recent one. If
    auto_diff
    is enabled and prior runs exist, run
    diff_analysis.py
    on current vs previous run and include the delta in the "Previous Review Delta" section.
  11. Verify each output against the raw files and datasheets before using the data in your report.
  12. Produce a unified report covering schematic analysis, PCB layout analysis, cross-domain findings, EMC risk assessment, simulation verification, thermal hotspots, and cross-reference findings. See
    references/report-generation.md
    for the report template.
  13. Disclose all review gaps explicitly — if thermal, lifecycle, gerber, datasheet extraction, or prior-review delta were not performed, add a short "Not performed / limits" section to the report instead of omitting them silently.
The more data sources you combine, the more confident the analysis. A schematic-only review misses layout issues; a PCB-only review misses design intent. Always use everything available.
原理图分析器顶级键:
analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, title_block, statistics,
bom, components, nets, subcircuits, ic_pin_analysis, design_analysis,
connectivity_issues, hierarchy_context, hierarchy_warning,
net_classifications, rail_voltages
可选字段(非空时存在):
pdn_impedance
,
sleep_current_audit
,
voltage_derating
,
power_budget
,
power_sequencing
,
bom_optimization
,
test_coverage
,
assembly_complexity
,
usb_compliance
,
inrush_analysis
,
sheets
(仅多页设计),
missing_info
,
bom_lock
,
project_settings
关键嵌套结构:
  • statistics
    :
    {total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}
  • bom[]
    :
    {reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}
  • components[]
    :
    {reference, value, footprint, lib_id, lib_name, type, category, mpn, datasheet, dnp, in_bom, parsed_value, ...}
  • nets{net_name}
    :
    {pins[], wires, labels[], ...}
    — 每个引脚:
    {component, pin_number, pin_name, pin_type, ...}
    不要使用
    ref
    pin
  • subcircuits[]
    : IC周边分组(
    {center_ic, ic_value, neighbor_components, ...}
    ),不是分类检测索引 — 请参考本文顶部的JSON字段速查表。
  • 检测到的子电路位于
    findings[]
    — 电源稳压器、分压器、RC/LC滤波器、反馈网络、运放/晶体管/桥路/晶体电路、电流检测、去耦、保护、蜂鸣器/扬声器、以太网/HDMI/内存接口、RF链路/匹配、BMS、按键矩阵、隔离屏障、可寻址LED链和设计观察结果均作为带有匹配
    Det.*
    检测器的检测结果输出。使用
    get_findings(data, Det.POWER_REGULATORS)
    等方法获取。v1.3之前的
    signal_analysis
    包装器及其顶级检测列表已移除。
PCB分析器顶级键:
analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, statistics, layers, setup,
nets, net_name_to_id, board_outline, component_groups, footprints,
tracks, vias, zones, keepout_zones, connectivity, net_lengths
可选字段:
power_net_routing
,
decoupling_placement
,
ground_domains
,
layer_transitions
,
silkscreen
,
board_metadata
,
dimensions
,
groups
,
net_classes
,
dfm_summary
,
placement_density
,
copper_presence_summary
,
board_thickness_mm
,
trace_proximity
(添加
--proximity
参数时存在)。之前位于顶级的部分(
thermal_analysis
,
thermal_pad_vias
,
tombstoning_risk
,
placement_analysis
,
current_capacity
,
copper_presence
,
dfm
)现在位于
findings[]
中。使用
--full
参数时,输出还包含
connectivity_graph
部分(请参考“连接图”章节)。
关键嵌套结构:
  • net_lengths
    列表(而非字典):
    [{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...]
    按长度降序排列
  • power_net_routing
    列表
    [{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]
  • footprints[]
    :
    {reference, value, footprint, layer, pads[], sch_path, sch_sheetname, sch_sheetfile, connected_nets[], ...}
  • statistics
    :
    {footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}
Gerber分析器顶级键:
analyzer_type, schema_version, summary, findings, trust_summary,
directory, generator, layer_count, statistics, completeness, alignment,
drill_classification, pad_summary, board_dimensions, gerbers, drills
工作流程: 分析KiCad项目时,扫描项目目录中的所有可用文件类型,并运行所有适用的分析器 — 而非仅用户提及的分析器。完整分析会使用所有可用数据。对所有分析器使用
--analysis-dir analysis/
参数,共享由清单追踪的单个运行文件夹。对于不需要缓存追踪的一次性运行,使用
--output file.json
参数替代。
开始以下设计审查工作流程前: 阅读
references/report-generation.md
。其中的报告结构、验证依据规则、跳过分析的披露和误报分类要求是审查工作流程的一部分,而非可选的后期优化。
  1. 扫描项目目录,查找
    .kicad_sch
    ,
    .kicad_pcb
    ,
    .kicad_pro
    , Gerber目录以及
    .net
    /
    .xml
    网表文件。
  2. 同步数据手册(请参考下文的数据手册获取) — 这是验证的先决条件,不可省略。没有数据手册,后续所有验证都仅为内部一致性检查 — 确认设计自身一致,但无法确认设计正确。在读取任何分析器输出前运行同步。若同步失败或无API密钥,使用备用方法(数据手册属性URL、通过
    digikey
    技能单独下载、询问用户)。若无法获取关键IC的数据手册,需在报告中显著说明为验证缺口。
  3. 运行核心分析器。若存在原理图,运行
    analyze_schematic.py
    ;若存在PCB,运行
    analyze_pcb.py --full
    ;若存在Gerber文件,运行
    analyze_gerbers.py
    。可能的话并行运行。
  4. 运行跨域分析 — 当同时存在原理图和PCB分析结果时,运行
    cross_analysis.py --schematic sch.json --pcb pcb.json
    。这能发现危险的跨域错误(连接器电流与走线宽度不匹配、ESD缺口、去耦充足性、原理图/PCB同步问题)。
  5. 运行EMC预合规分析 — 当同时存在原理图和PCB分析结果时,运行
    analyze_emc.py --schematic sch.json --pcb pcb.json
    。设计审查时必须运行此步骤,不可省略。EMC技能运行44项规则检查,涵盖地平面完整性、去耦、开关谐波、PDN阻抗、差分对偏移、ESD路径等。将结果包含在报告的EMC章节中。
  6. 运行SPICE仿真 — 先运行
    which ngspice ltspice xyce
    。若安装了任何仿真器,撰写报告前必须运行SPICE。将原理图分析JSON提交给
    spice
    技能。这能对照实际仿真结果验证滤波器频率、分压器比例、运放增益等。大多数电路板的SPICE仿真耗时<1秒,能发现静态分析器无法检测到的数值计算错误(错误的电阻比例、错误的截止频率电容)。若同时存在原理图和PCB分析结果,对高阻抗电路(>100K反馈分压器、LC滤波器、RF匹配网络)使用
    --parasitics
    参数。将结果包含在报告的仿真验证章节中。输出schema: 顶级键为
    summary
    ,
    simulation_results
    ,
    workdir
    ,
    total_elapsed_s
    ,
    simulator
    simulation_results[]
    中的每个条目包含:
    subcircuit_type
    ,
    components
    (参考编号列表,例如
    ["R5", "C3"]
    ),
    reference
    (合并的参考编号,例如
    "R5/C3"
    ),
    status
    pass
    /
    warn
    /
    fail
    /
    skip
    ),
    expected
    (参数值字典),
    simulated
    (测量值字典),
    delta
    (误差百分比字典)。
  7. 运行热分析 — 当同时存在原理图和PCB分析结果时,运行
    analyze_thermal.py --schematic schematic.json --pcb pcb.json
    。结合封装θJA和PCB热过孔校正估算结温。将结果包含在报告的热热点章节中。
  8. 运行生命周期审计(有网络访问权限且MPN可用时) — 通过
    analyze_schematic.py --lifecycle
    参数调用。通过分销商API检查元器件淘汰状态。将结果包含在报告的元器件生命周期章节中,或说明“未执行生命周期审计 — [原因:无API密钥/无网络/无MPN]”。
  9. 直接读取
    .kicad_pro
    项目文件
    (JSON格式),获取设计规则、网络类和DRC/ERC设置。
  10. 检查是否存在历史设计审查 — 扫描项目目录中的现有审查文件(
    *review*.md
    ,
    *design-review*.md
    )。若找到,读取最新的一份。若
    auto_diff
    已启用且存在历史运行记录,运行
    diff_analysis.py
    对比当前与之前的运行结果,并将差异包含在“历史审查差异”章节中。
  11. 在将数据用于报告前,对照原始文件和数据手册验证每个输出结果
  12. 生成统一报告,涵盖原理图分析、PCB布局分析、跨域检测结果、EMC风险评估、仿真验证、热热点和交叉参考检测结果。报告模板请参考
    references/report-generation.md
  13. 明确披露所有审查缺口 — 若未执行热分析、生命周期分析、Gerber分析、数据手册提取或历史审查差异分析,需在报告中添加简短的“未执行/限制”章节,而非静默省略。
结合的数据来源越多,分析的置信度越高。仅原理图审查会遗漏布局问题;仅PCB审查会遗漏设计意图。请始终使用所有可用数据。

Analysis Depth

分析深度

Default to thorough analysis unless the user asks for a quick review. The reason: the bugs that kill boards are the ones that look correct at a glance. A spot-check might confirm 5 ICs are correct while the 6th has pins 3 and 4 swapped — and that's the one that kills the board. Thoroughness principles:
  • Verify all components, not a sample. Pin-to-net errors on "simple" parts (reversed diode, wrong resistor in a divider, connector with wrong pin ordering) are just as fatal as swapped IC pins. Cover the full design.
  • Use datasheets as ground truth — not KiCad library symbols. The analyzer, raw schematic, and KiCad library files all tell you what the design says — only the manufacturer's PDF datasheet tells you what it should say. A library symbol with a wrong pin mapping is the most dangerous class of bug precisely because everything is internally consistent: schematic, PCB, and analyzer all agree, but the board doesn't work. Verifying a pin assignment against the
    .kicad_sym
    file is circular — it's the source of the potential error. Download datasheets before starting verification (see "Datasheet Acquisition" below), open the actual PDF for each IC, extract the pin function table, and cite page/section numbers when reporting verification results.
  • Assess plausibility, not just verifiability. When something can't be verified (missing MPN, missing datasheet), don't stop at "unverified." Use domain knowledge to assess whether the design choice aligns with common conventions or looks unusual. A 10kΩ I2C pull-up is unremarkable; a 100Ω I2C pull-up warrants a closer look even without a datasheet to check against. An SOT-23 NPN with BCE pinout matches the most common convention; one with CEB is unusual enough to flag. The goal is to distinguish "unverified but probably fine" from "unverified and suspicious." This applies to pinouts, passive values, circuit topologies, and component selection.
  • Think beyond what the analyzer detects. The analyzer only finds patterns it's programmed for. When a section has no automated data, consider whether that's because the design doesn't need it (fine — say so briefly) or because the analyzer can't detect it (reason about it manually). Not every section needs a paragraph — "Not applicable: battery-powered, no mains input" is sufficient. But don't let empty data create blind spots in areas that matter for the specific design.
除非用户要求快速审查,否则默认进行全面分析。原因:导致电路板失效的缺陷往往乍看之下是正确的。抽查可能确认5个IC正确,但第6个的引脚3和4被调换 — 而这正是导致电路板失效的原因。全面性原则:
  • 验证所有元器件,而非抽样。 “简单”元器件的引脚-网络错误(二极管反向、分压器电阻错误、连接器引脚顺序错误)与IC引脚调换一样致命。覆盖整个设计。
  • 以数据手册为基准,而非KiCad库符号。 分析器、原始原理图和KiCad库文件仅能告诉你设计声称的内容 — 只有厂商PDF数据手册能告诉你设计应该的内容。库符号的引脚映射错误是最危险的缺陷类型,因为所有内容内部一致:原理图、PCB和分析器结果都一致,但电路板无法工作。对照
    .kicad_sym
    文件验证引脚分配是循环验证 — 它正是潜在错误的来源。开始验证前下载数据手册(请参考下文的“数据手册获取”),打开每个IC的实际PDF,提取引脚功能表,并在报告验证结果时引用页码/章节号。
  • 评估合理性,而非仅可验证性。 当无法验证时(缺少MPN、缺少数据手册),不要仅停留在“未验证”。使用领域知识评估设计选择是否符合通用惯例或看起来异常。10kΩ的I2C上拉电阻很常见;100Ω的I2C上拉电阻即使没有数据手册也值得深入检查。BCE引脚顺序的SOT-23 NPN符合最常见的惯例;CEB引脚顺序的则异常到需要标记。目标是区分“未验证但可能没问题”与“未验证且可疑”。这适用于引脚顺序、无源器件参数、电路拓扑和元器件选型。
  • 超越分析器的检测范围思考。 分析器仅能检测其编程过的模式。当某个部分没有自动化数据时,考虑是因为设计不需要(没问题 — 简要说明)还是因为分析器无法检测(手动分析)。并非每个部分都需要段落说明 — “不适用:电池供电,无市电输入”就足够。但不要让空数据在对特定设计重要的领域造成盲点。

Datasheet Acquisition

数据手册获取

Datasheets are what separate a consistency check from a correctness check. Without them, you can confirm the design agrees with itself — but not that it matches the real-world parts. Obtain datasheets early in the workflow.
Automated sync (preferred): Run datasheet sync scripts early in the workflow. They download datasheets for all components with MPNs into a shared
datasheets/
directory with an
manifest.json
manifest. Run the preferred source first; if some parts fail, try others — they share the same directory and skip already-downloaded files.
bash
python3 <digikey-skill-path>/scripts/sync_datasheets_digikey.py <file.kicad_sch>
python3 <lcsc-skill-path>/scripts/sync_datasheets_lcsc.py <file.kicad_sch>
python3 <element14-skill-path>/scripts/sync_datasheets_element14.py <file.kicad_sch>
python3 <mouser-skill-path>/scripts/sync_datasheets_mouser.py <file.kicad_sch>
DigiKey is best (direct PDF URLs). element14 is reliable (no bot protection). LCSC works for LCSC-only parts. Mouser is a last resort (often blocks downloads).
Check for existing datasheets: Before downloading, look for:
  • <project>/datasheets/
    with
    manifest.json
    (from a previous sync)
  • <project>/docs/
    or
    <project>/documentation/
  • PDF files in the project directory whose names contain MPNs
  • Datasheet
    property URLs embedded in the KiCad symbols
Fallback methods when automated sync isn't available or misses parts:
  1. Use the
    Datasheet
    property URL from the schematic symbol — many KiCad libraries include direct PDF links
  2. Use the
    digikey
    skill to search by MPN and download individual datasheets
  3. Use web search to find the manufacturer's datasheet page
  4. Ask the user — if a critical component's datasheet can't be found automatically, tell the user which parts are missing and ask them to provide the datasheets. Don't silently skip verification because a datasheet wasn't available. Example: "I couldn't find datasheets for U3 (XYZ1234) and U7 (ABC5678). Can you provide them? I need them to verify the pinout and application circuit."
Structured datasheet extraction (for large designs or repeated reviews): Pre-extract datasheet specs into cached JSON for faster, more consistent pin verification. This is especially valuable for designs with 10+ ICs where re-reading PDFs from scratch each time is slow.
bash
python3 <skill-path>/scripts/datasheet_page_selector.py <pdf_path> --mpn <mpn> --category <category>
After reading the selected pages and producing an extraction JSON, score and cache it using
datasheet_score
and
datasheet_extract_cache
modules. Extractions are stored in
datasheets/extracted/<MPN>.json
and reused across reviews. The
datasheets
skill
owns the full extraction pipeline (schema, page selection, scoring rubric, consumer API) — see
skills/datasheets/SKILL.md
and its reference guides.
What to extract from each datasheet (note page/section/figure/equation numbers for citations):
  • Pin function table (pin number → name → function)
  • Absolute maximum ratings (voltage, current, temperature — including max continuous current through VCC/GND pins, which constrains inrush)
  • Recommended application circuit and required external components
  • Required component values (and the equations that derive them)
  • Thermal characteristics
For passives: While individual resistor/capacitor datasheets are rarely needed, verify the component values against the IC datasheets that specify them. The IC's datasheet says "use a 10µF input cap" — verify the schematic actually has 10µF there, not 1µF.
Anti-pattern: verification without datasheets. The most common failure mode in design review is verifying component connections against KiCad library symbols instead of manufacturer datasheets. This is circular — if the library symbol has a wrong pin mapping, the schematic, PCB, and analyzer output will all agree with each other (and with the wrong pinout). Only the datasheet reveals the error. This is especially dangerous for custom/community library symbols (e.g.,
sacmap:TPS61023
) where there's no upstream KiCad library as a secondary check. If you find yourself verifying a pinout by reading the
.kicad_sym
file or the analyzer's pin data and confirming it matches the schematic — stop. That's a consistency check, not a correctness check. Open the actual PDF datasheet, find the pin function table, and verify against that. Cite the datasheet page/section/figure number in your report so the designer can confirm your work.
数据手册是区分一致性检查与正确性检查的关键。没有数据手册,你只能确认设计自身一致 — 但无法确认是否与实际元器件匹配。请在工作流程早期获取数据手册。
自动同步(推荐): 工作流程早期运行数据手册同步脚本。它们会将所有带MPN的元器件的数据手册下载到共享的
datasheets/
目录,并生成
manifest.json
清单。优先运行首选来源;若部分元器件同步失败,尝试其他来源 — 它们共享同一目录,会跳过已下载的文件。
bash
python3 <digikey-skill-path>/scripts/sync_datasheets_digikey.py <file.kicad_sch>
python3 <lcsc-skill-path>/scripts/sync_datasheets_lcsc.py <file.kicad_sch>
python3 <element14-skill-path>/scripts/sync_datasheets_element14.py <file.kicad_sch>
python3 <mouser-skill-path>/scripts/sync_datasheets_mouser.py <file.kicad_sch>
DigiKey是最佳选择(直接PDF URL)。element14可靠(无机器人保护)。LCSC适用于仅在LCSC有售的元器件。Mouser是最后选择(经常阻止下载)。
检查现有数据手册: 下载前,查找:
  • <project>/datasheets/
    目录及其中的
    manifest.json
    (来自之前的同步)
  • <project>/docs/
    <project>/documentation/
    目录
  • 项目目录中名称包含MPN的PDF文件
  • KiCad符号中嵌入的
    Datasheet
    属性URL
自动同步不可用或遗漏元器件时的备用方法:
  1. 使用原理图符号中的
    Datasheet
    属性URL — 许多KiCad库包含直接PDF链接
  2. 使用
    digikey
    技能按MPN搜索并单独下载数据手册
  3. 使用网络搜索查找厂商的数据手册页面
  4. 询问用户 — 若无法自动获取关键元器件的数据手册,告知用户哪些元器件缺失,并请求提供数据手册。不要因数据手册不可用而静默跳过验证。示例:“我无法找到U3(XYZ1234)和U7(ABC5678)的数据手册。你能提供吗?我需要它们来验证引脚顺序和应用电路。”
结构化数据手册提取(适用于大型设计或重复审查): 提前将数据手册规格提取到缓存JSON中,以便更快、更一致地进行引脚验证。这对包含10+ IC的设计尤其有价值,每次从头读取PDF会很慢。
bash
python3 <skill-path>/scripts/datasheet_page_selector.py <pdf_path> --mpn <mpn> --category <category>
读取选定页面并生成提取JSON后,使用
datasheet_score
datasheet_extract_cache
模块进行评分和缓存。提取结果存储在
datasheets/extracted/<MPN>.json
中,可在多次审查中复用。
datasheets
技能
负责完整的提取流程(schema、页面选择、评分规则、消费者API) — 请参考
skills/datasheets/SKILL.md
及其参考指南。
从每个数据手册中提取的内容(引用页码/章节/图/公式编号):
  • 引脚功能表(引脚编号 → 名称 → 功能)
  • 绝对最大额定值(电压、电流、温度 — 包括VCC/GND引脚的最大连续电流,这会限制浪涌电流)
  • 推荐应用电路和所需外部元器件
  • 所需元器件参数(及推导它们的公式)
  • 热特性
对于无源器件: 虽然很少需要单个电阻/电容的数据手册,但需对照指定它们的IC数据手册验证元器件参数。IC数据手册要求“使用10µF输入电容” — 验证原理图中实际使用的是10µF,而非1µF。
反模式:无数据手册验证。 设计审查中最常见的失败模式是对照KiCad库符号验证元器件连接,而非厂商数据手册。这是循环验证 — 若库符号引脚映射错误,原理图、PCB和分析器输出都会相互一致(且与错误的引脚顺序一致)。只有数据手册能发现错误。这对自定义/社区库符号(如
sacmap:TPS61023
)尤其危险,因为没有上游KiCad库作为二次检查。若你发现自己通过读取
.kicad_sym
文件或分析器的引脚数据来验证引脚顺序,并确认与原理图一致 — 请停止。这是一致性检查,而非正确性检查。打开实际的PDF数据手册,找到引脚功能表,并对照其进行验证。在报告中引用数据手册的页码/章节/图编号,以便设计师确认你的工作。

Schematic + PCB Cross-Reference

原理图 + PCB交叉参考

When both files exist, cross-reference them. This catches the most expensive bugs — swapped pins, missing nets, and footprint mismatches pass DRC/ERC but produce non-functional boards.
  1. Component count: Schematic count (excluding power symbols) vs PCB footprint count.
  2. Net consistency: Verify schematic net names appear in PCB net declarations. Missing nets suggest incomplete routing or un-synced changes.
  3. Pin-net assignments: Compare schematic pin-to-net mapping against PCB pad-to-net mapping. Mismatches reveal swapped pins or library errors. Higher-risk areas:
    • Custom/community library symbols (may not match datasheet pinout)
    • Multi-unit symbols (op-amps, gate arrays) — unit-to-pin assignment errors
    • QFN/BGA packages — pad numbering mistakes
    • Transistors without MPNs — pinout ambiguity (see verification step 3)
    • Polarized components — anode/cathode orientation
    • Connectors — pin 1 orientation
  4. Footprint match: Schematic
    Footprint
    property vs actual PCB footprint (e.g., SOT-23 vs SOT-23-5).
  5. DNP consistency: DNP components in schematic should not have routing on PCB.
  6. Value/MPN consistency: Values and MPNs match between schematic and PCB properties.
The PCB analyzer's
sch_path
,
sch_sheetname
, and
sch_sheetfile
fields in each footprint enable automated cross-referencing.
当同时存在两个文件时,进行交叉参考。这能发现最昂贵的错误 — 引脚调换、缺失网络和封装不匹配会通过DRC/ERC,但会导致电路板无法工作。
  1. 元器件数量:原理图数量(排除电源符号)与PCB封装数量对比。
  2. 网络一致性:验证原理图网络名称是否存在于PCB网络声明中。缺失网络表明布线不完整或变更未同步。
  3. 引脚-网络分配:对比原理图引脚-网络映射与PCB焊盘-网络映射。不匹配表明引脚调换或库错误。高风险区域:
    • 自定义/社区库符号(可能与数据手册引脚顺序不符)
    • 多单元符号(运放、门阵列) — 单元-引脚分配错误
    • QFN/BGA封装 — 焊盘编号错误
    • 无MPN的晶体管 — 引脚顺序歧义(请参考验证步骤3)
    • 极性元器件 — 阳极/阴极方向
    • 连接器 — 引脚1方向
  4. 封装匹配:原理图
    Footprint
    属性与实际PCB封装对比(如SOT-23 vs SOT-23-5)。
  5. DNP一致性:原理图中的DNP元器件在PCB上不应有布线。
  6. 参数/MPN一致性:原理图与PCB属性中的参数和MPN一致。
PCB分析器每个封装中的
sch_path
,
sch_sheetname
,
sch_sheetfile
字段支持自动交叉参考。

Diff-Aware Design Comparison

差异感知设计对比

Compare two analysis JSON outputs to see what changed between design revisions (e.g., base branch vs PR, v1 vs v2). Use when the user says things like "compare designs", "what changed", "diff my schematic", "show changes from main", or "diff base vs head". Full reference:
references/diff-analysis.md
.
bash
undefined
对比两个分析器JSON输出,查看设计版本之间的变化(如基准分支与PR、v1与v2)。当用户说“对比设计”“有什么变化”“对比我的原理图”“显示与主分支的差异”或“对比基准与当前版本”时使用此功能。完整参考:
references/diff-analysis.md
bash
undefined

Compare two schematic analysis outputs (JSON to stdout)

对比两个原理图分析输出(JSON输出到标准输出)

python3 <skill-path>/scripts/diff_analysis.py base.json head.json
python3 <skill-path>/scripts/diff_analysis.py base.json head.json

Human-readable text output

人类可读文本输出

python3 <skill-path>/scripts/diff_analysis.py base.json head.json --text
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --text

Write to file, custom threshold (ignore <2% deltas)

写入文件,自定义阈值(忽略<2%的差异)

python3 <skill-path>/scripts/diff_analysis.py base.json head.json --output diff.json --threshold 2.0
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --output diff.json --threshold 2.0

Ignore small percentage changes (e.g., rounding noise)

忽略小百分比变化(如舍入误差)

python3 <skill-path>/scripts/diff_analysis.py base.json head.json --threshold 5.0 --text

Auto-detects analyzer type (schematic, PCB, EMC, SPICE). Reports:
- **Components**: new, removed, value/footprint/MPN changes
- **Signal analysis**: parameter shifts per detection type, driven by `detection_schema.SCHEMAS` identity and value fields
- **BOM**: added/removed line items, quantity changes
- **Connectivity/ERC**: new/resolved single-pin nets, floating nets, multi-driver nets, ERC warnings
- **EMC findings**: new/resolved findings with severity, risk score delta, per-net score changes
- **SPICE results**: status transitions (pass->fail regressions, fail->pass fixes), Monte Carlo concern changes
- **Severity classification**: `none` (no changes), `minor` (statistics only), `major` (component/signal/finding changes), `breaking` (SPICE regressions, new CRITICAL EMC findings, new ERC warnings)

Also used programmatically by `analysis_cache.should_create_new_run()` to decide whether new outputs warrant a new timestamped run folder.
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --threshold 5.0 --text

自动检测分析器类型(原理图、PCB、EMC、SPICE)。报告内容:
- **元器件**:新增、移除、参数/封装/MPN变更
- **信号分析**:每种检测类型的参数变化,由`detection_schema.SCHEMAS`标识和参数字段驱动
- **BOM**:新增/移除条目、数量变化
- **连接性/ERC**:新增/解决的单引脚网络、悬空网络、多驱动网络、ERC警告
- **EMC检测结果**:新增/解决的检测结果及严重程度、风险评分变化、每个网络的评分变化
- **SPICE结果**:状态转换(通过→失败的退化、失败→通过的修复)、蒙特卡洛关注点变化
- **严重程度分类**:`none`(无变化)、`minor`(仅统计数据变化)、`major`(元器件/信号/检测结果变化)、`breaking`(SPICE退化、新增CRITICAL EMC检测结果、新增ERC警告)

也被`analysis_cache.should_create_new_run()`用于决定新输出是否需要新的时间戳运行文件夹。

Thermal Hotspot Estimation

热热点估算

Estimates junction temperatures of power-dissipating components by combining schematic power data with PCB thermal infrastructure (copper pour, thermal vias, package type). Use when the user says "check thermals", "thermal analysis", "will this overheat", "junction temperature", "power dissipation", or "thermal design".
bash
undefined
结合原理图电源数据与PCB热基础设施(覆铜、热过孔、封装类型)估算耗元器件的结温。当用户说“检查热特性”“热分析”“这个会过热吗”“结温”“功耗”或“热设计”时使用此功能。
bash
undefined

Recommended: integrate into the current run

推荐:整合到当前运行中

python3 <skill-path>/scripts/analyze_thermal.py
-s analysis/<run_id>/schematic.json
-p analysis/<run_id>/pcb.json
--analysis-dir analysis/
python3 <skill-path>/scripts/analyze_thermal.py
-s analysis/<run_id>/schematic.json
-p analysis/<run_id>/pcb.json
--analysis-dir analysis/

Human-readable text report

人类可读文本报告

python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --text
python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --text

Custom ambient temperature (default: 25°C), one-off output file

自定义环境温度(默认:25°C),一次性输出文件

python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --ambient 40 -o thermal.json

Models each power component (LDO, switching regulator, shunt resistor) as a point heat source. Computes Tj = T_ambient + P_diss × Rθ_JA_effective, where Rθ_JA comes from a package lookup table (SOT-223: 60°C/W, QFN-5x5: 25°C/W, etc.) and is corrected for PCB thermal vias and copper pour. Rules:

| Rule | Condition | Severity |
|------|-----------|----------|
| TS-001 | Tj exceeds absolute maximum | CRITICAL |
| TS-002 | Tj within 15°C of absolute maximum | HIGH |
| TS-003 | Tj > 85°C (may affect nearby passives) | MEDIUM |
| TS-004 | P > 0.5W with no thermal vias | MEDIUM |
| TS-005 | Significant power, within safe limits | INFO |
| TP-001 | MLCC within 10mm of hot component | LOW |
| TP-002 | Electrolytic cap within 10mm of hot component | MEDIUM |

Thermal findings and assessments include the rich format envelope (detector, rule_id, summary, evidence_source, report_context). Rule IDs: TS-001..005 (safety), TP-001..002 (proximity), TH-DET (assessments).
python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --ambient 40 -o thermal.json

将每个功率元器件(LDO、开关稳压器、分流电阻)建模为点热源。计算Tj = T_ambient + P_diss × Rθ_JA_effective,其中Rθ_JA来自封装查找表(SOT-223: 60°C/W,QFN-5x5: 25°C/W等),并根据PCB热过孔和覆铜进行校正。规则:

| 规则 | 条件 | 严重程度 |
|------|-----------|----------|
| TS-001 | 结温超过绝对最大值 | CRITICAL |
| TS-002 | 结温接近绝对最大值(差值≤15°C) | HIGH |
| TS-003 | 结温>85°C(可能影响周边无源器件) | MEDIUM |
| TS-004 | 功耗>0.5W且无热过孔 | MEDIUM |
| TS-005 | 功耗较大,但在安全范围内 | INFO |
| TP-001 | MLCC与高温元器件距离≤10mm | LOW |
| TP-002 | 电解电容与高温元器件距离≤10mm | MEDIUM |

热检测结果和评估包含富格式结构(检测器、rule_id、摘要、evidence_source、report_context)。规则ID:TS-001..005(安全)、TP-001..002( proximity)、TH-DET(评估)。

Interactive "What-If" Parameter Sweep

交互式“假设分析”参数扫描

Instantly see the impact of component value changes on circuit behavior without re-running the full analyzer. Use when the user says "what if I change", "what happens if", "try a different value", "swap R5 to 4.7k", "parameter sweep", "what value gives me X", or wants to explore design trade-offs. Full reference:
references/what-if.md
.
bash
undefined
无需重新运行完整分析器,即可快速查看元器件参数变化对电路行为的影响。当用户说“如果我更改会怎样”“如果…会发生什么”“尝试不同参数”“将R5换成4.7k”“参数扫描”“什么参数能得到X”或想要探索设计权衡时使用此功能。完整参考:
references/what-if.md
bash
undefined

Single value change

单个参数变更

python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --text
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --text

Sweep: comma list or log range

扫描:逗号分隔列表或对数范围

python3 <skill-path>/scripts/what_if.py analysis.json R5=1k,2.2k,4.7k,10k --text python3 <skill-path>/scripts/what_if.py analysis.json R5=1k..100k:10 --text
python3 <skill-path>/scripts/what_if.py analysis.json R5=1k,2.2k,4.7k,10k --text python3 <skill-path>/scripts/what_if.py analysis.json R5=1k..100k:10 --text

Tolerance corner analysis (±5% worst-case)

容差边界分析(±5%最坏情况)

python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k+-5% C3=100n+-10% --text
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k+-5% C3=100n+-10% --text

Find the right value: inverse solver with E-series snapping

寻找合适参数:逆求解并对齐E系列值

python3 <skill-path>/scripts/what_if.py analysis.json --fix voltage_dividers[0] --target 3.3 --text python3 <skill-path>/scripts/what_if.py analysis.json --fix rc_filters[0] --target 1000 --text
python3 <skill-path>/scripts/what_if.py analysis.json --fix voltage_dividers[0] --target 3.3 --text python3 <skill-path>/scripts/what_if.py analysis.json --fix rc_filters[0] --target 1000 --text

EMC impact preview

EMC影响预览

python3 <skill-path>/scripts/what_if.py analysis.json C3=1u --emc --text
python3 <skill-path>/scripts/what_if.py analysis.json C3=1u --emc --text

SPICE re-simulation on affected subcircuits

对受影响子电路重新进行SPICE仿真

python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --spice --text
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --spice --text

Export patched JSON for further analysis (EMC, thermal, diff)

导出修补后的JSON用于进一步分析(EMC、热、差异)

python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --output patched.json

Patches component values in the analyzer JSON, recalculates derived fields (filter cutoff, divider ratio, opamp gain, crystal load, current sense range, regulator Vout), and shows before/after comparison with percentage deltas. Supports single changes, multi-point sweeps (comma or log-range), tolerance corner analysis, inverse fix suggestions with E-series snapping, EMC impact preview, PCB parasitic awareness (auto-discovered or via `--pcb`), and SPICE re-verification.
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --output patched.json

在分析器JSON中修补元器件参数,重新计算派生字段(滤波器截止频率、分压器比例、运放增益、晶体负载、电流检测范围、稳压器输出电压),并显示前后对比及百分比变化。支持单个变更、多点扫描(逗号或对数范围)、容差边界分析、逆求解建议并对齐E系列值、EMC影响预览、PCB寄生参数感知(自动发现或通过`--pcb`参数)和SPICE重新验证。

Findings Summary

检测结果摘要

Summarises findings across all analyzers in a run. Use when the user wants a top-N list, a severity-filtered view, or a machine-readable roll-up without reading individual JSON files. Reads the current run from
analysis/manifest.json
.
bash
undefined
汇总单次运行中所有分析器的检测结果。当用户需要前N个结果、按严重程度筛选的视图或无需读取单个JSON文件的机器可读汇总时使用此功能。从
analysis/manifest.json
读取当前运行记录。
bash
undefined

Top findings from the current run (default: top 20)

当前运行的主要检测结果(默认:前20个)

python3 <skill-path>/scripts/summarize_findings.py analysis/
python3 <skill-path>/scripts/summarize_findings.py analysis/

Limit to top 10 high-severity findings

限制为前10个高严重程度检测结果

python3 <skill-path>/scripts/summarize_findings.py analysis/ --top 10 --severity high
python3 <skill-path>/scripts/summarize_findings.py analysis/ --top 10 --severity high

JSON output for programmatic consumption

JSON输出用于程序调用

python3 <skill-path>/scripts/summarize_findings.py analysis/ --json
python3 <skill-path>/scripts/summarize_findings.py analysis/ --json

Summarise a specific run by ID

按ID汇总特定运行结果

python3 <skill-path>/scripts/summarize_findings.py analysis/ --run <run_id>

Flags: `--top N` (default 20), `--severity` (filter to `critical`/`high`/`warning`/`info`), `--run` (explicit run ID instead of latest), `--json` (machine-readable output).
python3 <skill-path>/scripts/summarize_findings.py analysis/ --run <run_id>

参数:`--top N`(默认20)、`--severity`(筛选`critical`/`high`/`warning`/`info`)、`--run`(指定运行ID而非最新运行)、`--json`(机器可读输出)。

Component Lifecycle & Temperature Audit

元器件生命周期与温度审计

Queries distributor APIs to check component lifecycle status (active, NRND, EOL, obsolete) and operating temperature range coverage. Use when the user says "check for obsolete parts", "lifecycle audit", "are any parts end of life", "temperature audit", "will this work at industrial temp range", or during production readiness reviews.
bash
undefined
查询分销商API检查元器件生命周期状态(active、NRND、EOL、obsolete)和工作温度范围覆盖情况。当用户说“检查过时元器件”“生命周期审计”“有元器件停产吗”“温度审计”“这个能在工业温度范围工作吗”或在量产就绪审查时使用此功能。
bash
undefined

Basic lifecycle check

基础生命周期检查

python3 <skill-path>/scripts/lifecycle_audit.py analysis.json
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json

With temperature range validation (preset or custom)

带温度范围验证(预设或自定义)

python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range industrial python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range "-40,105"
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range industrial python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range "-40,105"

Query specific distributors only

仅查询特定分销商

python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --only digikey,lcsc
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --only digikey,lcsc

Search for replacement parts when EOL/NRND found

发现EOL/NRND元器件时搜索替代元器件

python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --suggest-alternatives
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --suggest-alternatives

Save results

保存结果

python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --output lifecycle.json

Reads the analyzer JSON BOM section, extracts unique MPNs, queries distributors (LCSC no-auth, DigiKey, element14, Mouser) for lifecycle status and operating temperature. Temperature presets: `commercial` (0/70°C), `industrial` (-40/85°C), `extended` (-40/105°C), `automotive` (-40/125°C), `military` (-55/125°C). Also checks datasheet extraction cache for temperature data before making API calls.

The lifecycle audit produces rich format findings: LC-001 (obsolete/discontinued), LC-002 (last time buy), LC-003 (NRND), LC-004 (unknown status), LC-005 (single source), LC-006 (long lead time), LT-001 (temperature violation).

**Requires network access** — unlike the core analyzers, this script calls distributor APIs. Same environment variables as the distributor skills (DIGIKEY_CLIENT_ID/SECRET, MOUSER_SEARCH_API_KEY, ELEMENT14_API_KEY). LCSC requires no credentials.
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --output lifecycle.json

读取分析器JSON的BOM部分,提取唯一MPN,查询分销商(LCSC无需授权,DigiKey、element14、Mouser)获取生命周期状态和工作温度。温度预设:`commercial`(0/70°C)、`industrial`(-40/85°C)、`extended`(-40/105°C)、`automotive`(-40/125°C)、`military`(-55/125°C)。在调用API前,也会检查数据手册提取缓存中的温度数据。

生命周期审计生成富格式检测结果:LC-001(过时/停产)、LC-002(最后采购机会)、LC-003(NRND)、LC-004(状态未知)、LC-005(单一来源)、LC-006(长交期)、LT-001(温度违规)。

**需要网络访问** — 与核心分析器不同,此脚本会调用分销商API。使用与分销商技能相同的环境变量(DIGIKEY_CLIENT_ID/SECRET、MOUSER_SEARCH_API_KEY、ELEMENT14_API_KEY)。LCSC无需凭据。

Schematic Analyzer Rule IDs

原理图分析器规则ID

All schematic rule findings appear in
findings[]
. The following rule IDs are produced by the schematic analyzer:
RuleDetectorConditionSeverity
SS-001
audit_sourcing_gate
MPN coverage < 50%high
SS-002
audit_sourcing_gate
MPN coverage 50–80%warning
SS-003
audit_sourcing_gate
MPN coverage 80–100%info
NT-001
analyze_connectivity
Single-pin net: signal pinwarning
NT-001
analyze_connectivity
Single-pin net: power_out or passive pininfo
RS-001
audit_rail_sources
Rail has a declared source (direct, PWR_FLAG, or bridged jumper)info or warning
RS-002
audit_rail_sources
Rail depends on user closing an open jumperhigh
LB-001
detect_label_aliases
Net has >= 2 distinct global/hierarchical labels (power nets excluded)info
PP-001
audit_power_pin_dc_paths
IC power_in pin reaches a rail only through a capacitor (2-hop BFS)high
SS-001 is a pre-fab blocker — a
high
finding that should be resolved before ordering. NT-001 severity depends on pin type: signal pins (digital I/O, bidirectional) are
warning
; power_out and passive pins are
info
. RS-001 severity varies by confidence level in the detected source. PP-001 uses a 2-hop BFS over the net graph, rejecting capacitor edges, to confirm a direct DC path from a power rail to each IC power_in pin.
所有原理图规则检测结果都在
findings[]
中。原理图分析器生成以下规则ID:
规则检测器条件严重程度
SS-001
audit_sourcing_gate
MPN覆盖率<50%high
SS-002
audit_sourcing_gate
MPN覆盖率50–80%warning
SS-003
audit_sourcing_gate
MPN覆盖率80–100%info
NT-001
analyze_connectivity
单引脚网络:信号引脚warning
NT-001
analyze_connectivity
单引脚网络:power_out或无源引脚info
RS-001
audit_rail_sources
电源轨有声明的来源(直接、PWR_FLAG或桥接跳线)info或warning
RS-002
audit_rail_sources
电源轨依赖用户闭合开路跳线high
LB-001
detect_label_aliases
网络有≥2个不同的全局/层级标签(电源网络除外)info
PP-001
audit_power_pin_dc_paths
IC power_in引脚仅通过电容连接到电源轨(2-hop BFS)high
SS-001是制板前阻塞问题 —
high
严重程度的检测结果应在下单前解决。NT-001的严重程度取决于引脚类型:信号引脚(数字I/O、双向)为
warning
;power_out和无源引脚为
info
。RS-001的严重程度根据检测到的来源的置信度等级而变化。PP-001使用网络图的2-hop BFS(排除电容边),确认每个IC power_in引脚与电源轨之间存在直接DC路径。

Reference Files

参考文件

Detailed methodology and format documentation lives in reference files. Read these as needed — they provide deep-dive content beyond what the scripts output automatically.
ReferenceLinesWhen to Read
schematic-analysis.md
1133Deep schematic review: datasheet validation, design patterns, error taxonomy, tolerance stacking, GPIO audit, motor control, battery life, supply chain
pcb-layout-analysis.md
447Advanced PCB: impedance calculations, differential pairs, return paths, copper balance, edge clearance, copper-sensitive components (capacitive touch, antennas), custom analysis scripts
output-schema.md
293Full analyzer JSON schema with field names, types, and common extraction patterns
file-formats.md
379Manual file inspection: S-expression structure, field-by-field docs for all KiCad file types, version detection
gerber-parsing.md
729Gerber/Excellon format details, X2 attributes, analysis techniques
pdf-schematic-extraction.md
315PDF schematic analysis: extraction workflow, notation conventions, KiCad translation
supplementary-data-sources.md
288Legacy KiCad 5 data recovery: netlist parsing, cache library, PCB cross-reference
net-tracing.md
120Manual net tracing: coordinate math, Y-axis inversion, rotation transforms
manual-schematic-parsing.md
289Fallback when schematic script fails
manual-pcb-parsing.md
467Fallback when PCB script fails
manual-gerber-parsing.md
621Fallback when Gerber script fails
report-generation.md
614Report template (critical findings at top), analyzer output field reference (schematic/PCB/gerber), severity definitions, writing principles, domain-specific focus areas, known analyzer limitations
standards-compliance.md
638IPC/IEC standards tables: conductor spacing (IPC-2221A Table 6-1), current capacity (IPC-2221A/IPC-2152), annular rings, hole sizes, impedance, via protection (IPC-4761), creepage/clearance (ECMA-287/IEC 60664-1). Consider for all boards; auto-trigger for professional/industrial designs, high voltage, mains input, or safety isolation.
design-intent.md
Design intent resolution, target market / certification / power constraints that gate findings by context
diff-analysis.md
How
diff_analysis.py
compares two analyzer runs and emits severity-ranked change reports
what-if.md
How
what_if.py
patches component values, recalculates derived fields, and suggests fixes for feedback dividers / crystal load caps / cap derating
config-reference.md
.kicad-happy.json
schema — project config for analysis cache, suppressions, design intent, risk scoring
datasheet-verification.md
Automated cross-check of schematic connections against structured datasheet extractions (pin voltage, required externals, decoupling adequacy)
For script internals, data structures, signal analysis patterns, and batch test suite documentation, see
scripts/README.md
.
详细方法学和格式文档位于参考文件中。按需阅读 — 它们提供脚本自动输出之外的深入内容。
参考文件行数阅读时机
schematic-analysis.md
1133深入原理图审查:数据手册验证、设计模式、错误分类、容差叠加、GPIO审计、电机控制、电池寿命、供应链
pcb-layout-analysis.md
447高级PCB分析:阻抗计算、差分对、返回路径、覆铜平衡、边缘间距、对覆铜敏感的元器件(电容触摸、天线)、自定义分析脚本
output-schema.md
293完整分析器JSON schema,包含字段名、类型和常见提取模式
file-formats.md
379手动文件检查:S表达式结构、所有KiCad文件类型的逐字段文档、版本检测
gerber-parsing.md
729Gerber/Excellon格式细节、X2属性、分析技术
pdf-schematic-extraction.md
315PDF原理图分析:提取工作流程、符号约定、KiCad转换
supplementary-data-sources.md
288旧版KiCad 5数据恢复:网表解析、缓存库、PCB交叉参考
net-tracing.md
120手动网络追踪:坐标计算、Y轴反转、旋转变换
manual-schematic-parsing.md
289原理图脚本失败时的备用方法
manual-pcb-parsing.md
467PCB脚本失败时的备用方法
manual-gerber-parsing.md
621Gerber脚本失败时的备用方法
report-generation.md
614报告模板(顶部显示关键检测结果)、分析器输出字段参考(原理图/PCB/Gerber)、严重程度定义、写作原则、特定领域重点、已知分析器限制
standards-compliance.md
638IPC/IEC标准表:导体间距(IPC-2221A表6-1)、载流能力(IPC-2221A/IPC-2152)、焊环、孔径、阻抗、过孔保护(IPC-4761)、爬电距离/电气间隙(ECMA-287/IEC 60664-1)。所有电路板均需考虑;专业/工业设计、高压、市电输入或安全隔离设计自动触发。
design-intent.md
设计意图解析、目标市场/认证/电源约束,用于根据上下文调整审查严重程度
diff-analysis.md
diff_analysis.py
如何对比两个分析器运行结果并生成严重程度排序的变更报告
what-if.md
what_if.py
如何修补元器件参数、重新计算派生字段,并为反馈分压器/晶体负载电容/电容降额提供修复建议
config-reference.md
.kicad-happy.json
schema — 分析缓存、抑制规则、设计意图、风险评分的项目配置
datasheet-verification.md
原理图连接与结构化数据手册提取的自动交叉检查(引脚电压、所需外部器件、去耦充足性)
脚本内部实现、数据结构、信号分析模式和批量测试套件文档请参考
scripts/README.md

File Types Quick Reference

文件类型快速参考

ExtensionFormatPurpose
.kicad_pro
JSONProject settings, net classes, DRC/ERC severity, BOM fields
.kicad_sch
S-exprSchematic sheet (symbols, wires, labels, hierarchy)
.kicad_pcb
S-exprPCB layout (footprints, tracks, vias, zones, board outline)
.kicad_sym
S-exprSymbol library (schematic symbols with pins, graphics)
.kicad_mod
S-exprSingle footprint (in
.pretty/
directory)
.kicad_dru
CustomCustom design rules (DRC constraints)
fp-lib-table
/
sym-lib-table
S-exprLibrary path tables
.sch
/
.lib
/
.dcm
LegacyKiCad 5 schematic, symbol library, descriptions
.net
/
.xml
S-expr/XMLNetlist export, BOM export
.gbr
/
.g*
/
.drl
Gerber/ExcellonManufacturing files (copper, mask, silk, outline, drill)
For version detection and detailed field-by-field format documentation, read
references/file-formats.md
.
扩展名格式用途
.kicad_pro
JSON项目设置、网络类、DRC/ERC严重程度、BOM字段
.kicad_sch
S表达式原理图页面(符号、导线、标签、层级)
.kicad_pcb
S表达式PCB布局(封装、走线、过孔、区域、电路板轮廓)
.kicad_sym
S表达式符号库(带引脚、图形的原理图符号)
.kicad_mod
S表达式单个封装(位于
.pretty/
目录)
.kicad_dru
自定义自定义设计规则(DRC约束)
fp-lib-table
/
sym-lib-table
S表达式库路径表
.sch
/
.lib
/
.dcm
旧版KiCad 5原理图、符号库、描述
.net
/
.xml
S表达式/XML网表导出、BOM导出
.gbr
/
.g*
/
.drl
Gerber/Excellon制造文件(覆铜、阻焊、丝印、轮廓、钻孔)
版本检测和详细的逐字段格式文档请阅读
references/file-formats.md

Analysis Strategies

分析策略

Deep Schematic Analysis

深入原理图分析

For a thorough datasheet-driven schematic review — identifying subcircuits, fetching datasheets, validating component values against manufacturer recommendations, comparing against common design patterns, detecting errors, and suggesting improvements — read
references/schematic-analysis.md
. Use this reference whenever the user asks to review, validate, or analyze a schematic in depth.
Fetching datasheets: When the analysis requires datasheet data, use the DigiKey API as the preferred source (see the
digikey
skill) — it returns direct PDF URLs via the
DatasheetUrl
field without web scraping. Search by MPN from the schematic's component properties. Fall back to web search only for parts not on DigiKey.
如需进行全面的基于数据手册的原理图审查 — 识别子电路、获取数据手册、对照厂商建议验证元器件参数、对比通用设计模式、检测错误并提出改进建议,请阅读
references/schematic-analysis.md
。每当用户要求深入审查、验证或分析原理图时,使用此参考文件。
获取数据手册: 当分析需要数据手册数据时,优先使用DigiKey API(请参考
digikey
技能) — 它通过
DatasheetUrl
字段返回直接PDF URL,无需网页抓取。根据原理图元器件属性中的MPN进行搜索。仅当元器件不在DigiKey上时,才回退到网络搜索。

Deep PCB Analysis

深入PCB分析

For advanced layout analysis beyond what the PCB analyzer script provides — impedance calculations from stackup parameters, DRC rule authoring, power electronics design review techniques, differential pair validation, return path analysis, copper balance assessment, board edge clearance rules, and manual script-writing patterns — read
references/pcb-layout-analysis.md
.
Most routine PCB analysis (via types, annular ring, placement, connectivity, thermal vias, current capacity, signal integrity, DFM scoring, tombstoning risk, thermal pad vias) is handled automatically by
analyze_pcb.py
. Use the reference for deeper manual investigation.
如需进行PCB分析器脚本之外的高级布局分析 — 基于叠层参数的阻抗计算、DRC规则编写、电力电子设计审查技术、差分对验证、返回路径分析、覆铜平衡评估、电路板边缘间距规则和手动脚本编写模式,请阅读
references/pcb-layout-analysis.md
大多数常规PCB分析(过孔类型、焊环、布局、连接性、热过孔、载流能力、信号完整性、DFM评分、立碑风险、热焊盘过孔)由
analyze_pcb.py
自动处理。使用参考文件进行更深入的手动调查。

Design Intent

设计意图

For interpreting auto-detected design intent and calibrating review severity by product class and target market (hobby vs consumer vs industrial vs medical vs automotive vs aerospace), read
references/design-intent.md
. Check the
design_intent
object in analysis output to understand the design context.
如需解释自动检测到的设计意图,并根据产品类别和目标市场(业余/消费/工业/医疗/汽车/航空航天)调整审查严重程度,请阅读
references/design-intent.md
。检查分析输出中的
design_intent
对象以理解设计上下文。

Probing Analyzer JSON

探查分析器JSON

During a review you will often run one-off
python3 -c "import json; ..."
probes to inspect analyzer output (pin-nets, rail voltages, specific finding contents, etc.). Two practices that materially improve the user's ability to follow along:
Announce what you're checking before each probe. One concise sentence before the script — not after, not in a comment inside the script. The user should be able to read only the narrative and understand the review flow without opening every tool call.
  • Bad:
    [Bash] python3 -c "import json; d = json.load(open('analysis/.../schematic.json')); print([...])"
    with no surrounding prose.
  • Good: "Checking whether U3's EN pin is tied to +BATT directly or through a divider." then the probe.
  • Good: "Verifying the detected TPS61023 topology matches the datasheet (buck-boost expected)." then the probe.
The narrative matters most for probes that investigate why something looks wrong — those are the moments a user loses context fastest.
Defensive patterns for JSON-shape uncertainty. Analyzer output has heterogeneous shapes (lists of dicts, dicts keyed by ref, optional sections, nested paths). Scripts that assume the wrong shape crash mid-probe.
  • Before slicing, check type:
    x[:3]
    on a dict raises
    KeyError: slice(None, 3, None)
    . Use
    list(x.values())[:3]
    or
    list(x.items())[:3]
    for dicts.
  • Before
    min()
    /
    max()
    , check non-empty:
    min([])
    raises
    ValueError: min() iterable argument is empty
    . Use
    min(items, default=None)
    or guard with
    if items:
    .
  • Use
    .get("key", default)
    not
    ["key"]
    when a section may be absent (many sections are optional based on what the analyzer found).
  • isinstance(x, list)
    vs
    isinstance(x, dict)
    components
    is a list of dicts,
    nets
    is a dict keyed by net name. Check the schema reference before iterating.
  • When a finding field can be a list of strings OR a list of dicts (rare but happens in legacy-shape sections), handle both:
    r = c if isinstance(c, str) else c.get("reference", "")
    .
  • Pads/components with missing data:
    pad.get("abs_x")
    can be
    None
    ; guard before arithmetic.
Small investment, much lower friction.
审查过程中,你经常会运行一次性的
python3 -c "import json; ..."
命令来探查分析器输出(引脚-网络、电源轨电压、特定检测结果内容等)。以下两种做法能显著提升用户的跟随体验:
每次探查前说明你要检查的内容。 在脚本前添加一句简洁的话 — 不要在之后或脚本注释中说明。用户应该仅通过叙述就能理解审查流程,无需打开每个工具调用。
  • 错误示例:
    [Bash] python3 -c "import json; d = json.load(open('analysis/.../schematic.json')); print([...])"
    ,无任何上下文说明。
  • 正确示例:“检查U3的EN引脚是直接连接到+BATT还是通过分压器连接。”然后运行探查命令。
  • 正确示例:“验证检测到的TPS61023拓扑是否与数据手册一致(预期为升降压)。”然后运行探查命令。
当探查内容是为了调查“为什么看起来有问题”时,叙述尤为重要 — 这些时刻用户最容易失去上下文。
针对JSON结构不确定性的防御性模式。 分析器输出具有异构结构(字典列表、按参考编号键控的字典、可选部分、嵌套路径)。假设错误结构的脚本会在探查过程中崩溃。
  • 切片前检查类型:对字典使用
    x[:3]
    会触发
    KeyError: slice(None, 3, None)
    。对字典使用
    list(x.values())[:3]
    list(x.items())[:3]
  • 使用
    min()
    /
    max()
    前检查非空:
    min([])
    会触发
    ValueError: min() iterable argument is empty
    。使用
    min(items, default=None)
    或用
    if items:
    判断。
  • 当部分可能不存在时,使用
    .get("key", default)
    而非
    ["key"]
    (许多部分根据分析器的检测结果可选)。
  • isinstance(x, list)
    vs
    isinstance(x, dict)
    components
    是字典列表,
    nets
    是按网络名称键控的字典。迭代前检查schema参考。
  • 当检测结果字段可能是字符串列表或字典列表(罕见但在旧版结构部分存在),需同时处理两种情况:
    r = c if isinstance(c, str) else c.get("reference", "")
  • 缺少数据的焊盘/元器件:
    pad.get("abs_x")
    可能为
    None
    ;进行算术运算前需判断。
投入少量精力,能大幅降低摩擦。

Quick Review Checklists

快速审查清单

Schematic — verify: decoupling caps on every IC VCC/GND pair, I2C pull-ups, reset pin circuits, unconnected pins have no-connect markers, consistent net naming across sheets, ESD protection on external connectors, power sequencing (EN/PG), adequate bulk capacitance.
PCB — verify: power trace widths for current (IPC-2221), via current capacity, creepage/clearance for high voltage, decoupling cap proximity to IC power pins, continuous ground plane (no splits under signals), controlled impedance traces (USB/DDR), board outline closed polygon, silkscreen readability, thermal via count for every exposed-pad IC (report the count and compare against the datasheet's recommended range — this is one of the most common QFN/DFN layout errors), keepout zone enforcement for copper-sensitive components (touch pads and antennas — confirming copper absence isn't enough because it could be accidental; check that keepout zones exist as DRC rules), differential pair length deltas with protocol-specific tolerance (compute the delta and cite the spec — raw lengths alone don't tell the designer if there's a problem), pad-to-net cross-reference at PCB level for all ICs/transistors/connectors (catches library footprint pin numbering errors that are invisible to DRC/ERC — the most dangerous class of PCB bug). Consider
references/standards-compliance.md
for IPC/IEC standard values — conductor spacing and current capacity are relevant for most boards; creepage/clearance and via protection apply to mains-connected or safety-isolated designs.
Common bugs (ranked by board-killing potential): swapped IC pins (library symbol vs datasheet pinout — invisible to DRC/ERC), transistor pinout ambiguity (SOT-23 without MPN — symbol assumes a pin ordering that may not match the real part; assess plausibility against common conventions when verification isn't possible), wrong footprint pad numbering, missing nets from un-synced schematic→PCB, wrong package variant (SOT-23 vs SOT-23-5), floating digital inputs, missing bulk caps, reversed polarity, incorrect feedback divider values, wrong crystal load caps, USB impedance mismatch, QFN thermal pad missing vias, connector pinout errors, unusual passive values (a value that's technically valid but uncommon for the application — e.g., a non-standard pull-up resistance, an unusual decoupling capacitor value).
原理图 — 验证:每个IC VCC/GND对都有去耦电容、I2C上拉电阻、复位引脚电路、未连接引脚有无连接标记、跨页面网络命名一致、外部连接器有ESD保护、电源时序(EN/PG)、足够的 bulk电容。
PCB — 验证:电源走线宽度符合电流要求(IPC-2221)、过孔载流能力、高压爬电距离/电气间隙、去耦电容靠近IC电源引脚、连续地平面(信号下方无分割)、受控阻抗走线(USB/DDR)、电路板轮廓为闭合多边形、丝印可读性、每个裸露焊盘IC的热过孔数量(报告数量并与数据手册建议范围对比 — 这是QFN/DFN布局最常见的错误之一)、对覆铜敏感的元器件(触摸焊盘和天线)的禁布区规则强制执行(确认覆铜缺失是不够的,因为可能是意外;需检查是否存在作为DRC规则的禁布区)、差分对长度差符合协议特定容差(计算差值并引用规范 — 仅原始长度无法告知设计师是否存在问题)、所有IC/晶体管/连接器在PCB层面的焊盘-网络交叉参考(能发现DRC/ERC无法检测到的库封装焊盘编号错误 — 这是最危险的PCB缺陷类型)。请参考
references/standards-compliance.md
获取IPC/IEC标准值 — 导体间距和载流能力适用于大多数电路板;爬电距离/电气间隙和过孔保护适用于市电连接或安全隔离设计。
常见缺陷(按电路板失效可能性排序): IC引脚调换(库符号与数据手册引脚顺序不符 — DRC/ERC无法检测)、晶体管引脚顺序歧义(无MPN的SOT-23 — 符号假设的引脚顺序可能与实际元器件不符;无法验证时根据通用惯例评估合理性)、错误的封装焊盘编号、原理图→PCB未同步导致的缺失网络、错误的封装变体(SOT-23 vs SOT-23-5)、悬空数字输入、缺失bulk电容、极性反向、错误的反馈分压器参数、错误的晶体负载电容、USB阻抗不匹配、QFN热焊盘缺少过孔、连接器引脚顺序错误、异常无源器件参数(技术上有效但在应用中不常见 — 如非标准上拉电阻、不常见的去耦电容参数)。

Report Generation

报告生成

When producing a design review report, read
references/report-generation.md
for the standard report template, severity definitions, writing principles, and domain-specific focus areas. The report format covers: overview, component summary, power tree, analyzer verification (spot-checks), signal/power/design analysis review, quality & manufacturing, prioritized issues table, positive findings, and known analyzer gaps. Always cross-reference analyzer output against the raw schematic before reporting findings.
生成设计审查报告时,请阅读
references/report-generation.md
获取标准报告模板、严重程度定义、写作原则和特定领域重点。报告格式包含:概述、元器件摘要、电源树、分析器验证(抽查)、信号/电源/设计分析审查、质量与制造、优先级问题表、正面检测结果和已知分析器缺口。报告检测结果前,始终对照原始原理图交叉验证分析器输出。

Design Comparison

设计对比

When comparing two designs, diff: component counts/types, net classes/design rules, track widths/via sizes, board dimensions/layer count, power supply topology, KiCad version differences.
对比两个设计时,需对比:元器件数量/类型、网络类/设计规则、走线宽度/过孔尺寸、电路板尺寸/层数、电源拓扑、KiCad版本差异。

Security Architecture

安全架构

All analysis scripts process untrusted input (user-provided KiCad files, third-party PDF datasheets, distributor API responses). The parsing architecture mitigates prompt injection and code execution risks:
  • Deterministic parsers: S-expression files (
    .kicad_sch
    ,
    .kicad_pcb
    ) are parsed by a dedicated recursive-descent parser (
    sexp_parser.py
    ) — not
    eval()
    ,
    exec()
    , or any code execution primitive. The parser produces Python lists/strings only.
  • Structured JSON boundary: All analyzer output is structured JSON with a fixed schema. External content (component values, net names, datasheet text) is treated as data fields, never as instructions or code.
  • PDF processing: Datasheet PDFs are processed by
    pdftotext
    (external binary, list-based args — no shell injection) and page content is passed to the LLM for structured extraction. Extracted data is validated against a 5-dimension quality rubric before caching.
  • No shell commands from input: No analyzer constructs shell commands from file content. Subprocess calls use list-based arguments exclusively.
  • Read-only by default: Analysis scripts never modify input files. BOM write-back requires an explicit
    --write
    flag.
  • Distributor API scope: Network requests are limited to known distributor APIs (DigiKey, Mouser, LCSC, element14) for datasheet downloads and component lookups. Only MPNs are sent — no design data leaves the local machine.
所有分析脚本处理不受信任的输入(用户提供的KiCad文件、第三方PDF数据手册、分销商API响应)。解析架构可缓解提示注入和代码执行风险:
  • 确定性解析器:S表达式文件(
    .kicad_sch
    ,
    .kicad_pcb
    )由专用的递归下降解析器(
    sexp_parser.py
    )解析 — 不使用
    eval()
    exec()
    或任何代码执行原语。解析器仅生成Python列表/字符串。
  • 结构化JSON边界:所有分析器输出为具有固定schema的结构化JSON。外部内容(元器件参数、网络名称、数据手册文本)被视为数据字段,而非指令或代码。
  • PDF处理:数据手册PDF由
    pdftotext
    (外部二进制文件,基于列表的参数 — 无shell注入)处理,页面内容传递给LLM进行结构化提取。提取的数据在缓存前需通过5维度质量规则验证。
  • 无来自输入的shell命令:分析器从不根据文件内容构造shell命令。子进程调用仅使用基于列表的参数。
  • 默认只读:分析脚本从不修改输入文件。BOM回写需要显式的
    --write
    参数。
  • 分销商API范围:网络请求仅限于已知分销商API(DigiKey、Mouser、LCSC、element14),用于数据手册下载和元器件查找。仅发送MPN — 无设计数据离开本地机器。