[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MDZ1P6MTHE5E3249CEACJG":3,"skill-same:01M6MDZ1P6MTHE5E3249CEACJG":593},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6MDZ1P6MTHE5E3249CEACJG","kicad",null,"Analyze KiCad projects and PDF schematics: schematics, PCB layouts, Gerbers, footprints, symbols, netlists, and design rules. Reviews designs for bugs, traces nets, cross-references schematic to PCB, extracts BOM data, checks DRC\u002FERC, DFM, power trees, and regulator circuits. Every finding carries a confidence label and evidence source with trust_summary rollup. Analyzes PDF schematics from dev boards, reference designs, eval kits, and datasheets. Supports KiCad 5–10. Use whenever the user mentions .kicad_sch, .kicad_pcb, .kicad_pro, PCB design review, schematic analysis, PDF schematics, reference designs, Gerber files, DRC\u002FERC, netlist issues, BOM extraction, signal tracing, power budget, DFM, or wants to understand, debug, compare, or review any hardware design. Also for \"check my board\", \"review before fab\", \"what's wrong with my schematic\", \"is this ready to order\", \"check my power supply\", \"verify this circuit\", OSHWA certification readiness, or any electronics\u002FPCB design question.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1571,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"files","circuit","schematic","gerber","pcb","reviews","supply","trees","DRC","PDF","ready","power","question","eval","analyze","projects","Budget","tracing","design","2026-11-10 10:12:30",false,"---\nname: kicad\ndescription: >-\n  Analyze KiCad projects and PDF schematics: schematics, PCB layouts, Gerbers,\n  footprints, symbols, netlists, and design rules. Reviews designs for bugs,\n  traces nets, cross-references schematic to PCB, extracts BOM data, checks\n  DRC\u002FERC, DFM, power trees, and regulator circuits. Every finding carries a\n  confidence label and evidence source with trust_summary rollup. Analyzes PDF\n  schematics from dev boards, reference designs, eval kits, and datasheets.\n  Supports KiCad 5–10. Use whenever the user mentions .kicad_sch, .kicad_pcb,\n  .kicad_pro, PCB design review, schematic analysis, PDF schematics, reference\n  designs, Gerber files, DRC\u002FERC, netlist issues, BOM extraction, signal\n  tracing, power budget, DFM, or wants to understand, debug, compare, or\n  review any hardware design. Also for \"check my board\", \"review before fab\",\n  \"what's wrong with my schematic\", \"is this ready to order\", \"check my power\n  supply\", \"verify this circuit\", OSHWA certification readiness, or any\n  electronics\u002FPCB design question.\n---\n\n# KiCad Project Analysis Skill\n\n## Related Skills\n\n| Skill | Purpose |\n|-------|---------|\n| `bom` | BOM extraction, enrichment, ordering, and export workflows |\n| `digikey` | Search DigiKey for parts (prototype sourcing) |\n| `mouser` | Search Mouser for parts (secondary prototype source) |\n| `lcsc` | Search LCSC for parts (production sourcing, JLCPCB) |\n| `element14` | Search Newark\u002FFarnell\u002Felement14 (international sourcing, reliable datasheets) |\n| `jlcpcb` | PCB fabrication & assembly ordering |\n| `pcbway` | Alternative PCB fabrication & assembly |\n| `spice` | SPICE simulation verification of detected subcircuits |\n| `emc` | EMC pre-compliance risk analysis — consumes schematic + PCB analyzer output |\n\n**Handoff guidance:** Use this skill to parse schematics\u002FPCBs and extract structured data. Hand off to `bom` for BOM enrichment, pricing, and ordering. Hand off to `digikey`\u002F`mouser`\u002F`lcsc`\u002F`element14` for part searches and datasheet fetching. Hand off to `jlcpcb`\u002F`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.\n\n**Before analysis:** When the user asks to analyze or review a KiCad project, check whether a `datasheets\u002F` 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.\n\n**If you see a `DS-001` finding in the analyzer output** (severity `error`, detector `audit_datasheet_coverage`), the review cannot make any verified claim. Stop and either (a) run the datasheet sync via `digikey` \u002F `mouser` \u002F `lcsc` \u002F `element14` (whichever has credentials\u002Fstock), (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.\n\n## Design Review Contract\n\nWhen 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:\n\n1. Read the full workflow in this `SKILL.md`, not just the analyzer command sections.\n2. Read `references\u002Freport-generation.md` before writing the report.\n3. Run every applicable analyzer for the files present in the project, then say explicitly which ones were and were not run.\n4. Perform raw-file and datasheet cross-verification before claiming anything is \"verified\".\n5. Triage likely analyzer false positives before elevating them into blockers.\n6. If a required step could not be done, state it as a review gap, not as silent omission.\n\nTreat this as the minimum bar. Analyzer JSON alone is not the final review.\n\n### Minimum Review Checklist\n\nFor a full design review, explicitly account for each item below in the report:\n\n- `datasheets\u002F` present, synced, or verification gap stated\n- `analyze_schematic.py`\n- `analyze_pcb.py --full --schematic`\n- `cross_analysis.py`\n- `analyze_emc.py`\n- SPICE simulation when any simulator is installed\n- `analyze_thermal.py` when both schematic and PCB JSON exist\n- `analyze_gerbers.py` when fabrication outputs exist\n- lifecycle audit when network access and MPN coverage allow it\n- prior review \u002F prior run delta check\n- raw schematic\u002FPCB spot-verification elevated to full verification for critical parts\n- explicit report sections for blockers, verification basis, false positives, and skipped analyses\n\nIf an item is not applicable, say why. If it was skipped, say why. If it failed, say how that limits confidence.\n\n### Common Review Failure Modes\n\nThese are the failure modes this contract is meant to prevent:\n\n- Stopping after schematic + PCB + EMC output and calling it a complete review\n- Reporting analyzer findings without checking whether they are expected layout artifacts\n- Claiming \"verified\" without direct datasheet evidence or structured extraction evidence\n- Omitting thermal, lifecycle, prior-review delta, or gerber checks without disclosure\n- Writing a report that lacks a verdict, blockers table, verification basis, or skipped-analysis notes\n- Reading only the first part of this skill and missing the design-review workflow later in the file\n\n## PDF Schematic Analysis\n\nThis skill also handles **PDF schematics** — reference designs, dev board schematics, eval board docs, application notes, and datasheet typical-application circuits. Common use cases:\n\n- Analyze a manufacturer's reference design to understand the circuit\n- Extract a subcircuit (power supply, USB interface, sensor front-end) to incorporate into your own KiCad design\n- Compare a PDF reference design against your own schematic\n- Extract a full BOM from a PDF schematic\n- Validate component values in a PDF against current datasheets\n\n**Workflow:** Read the PDF pages visually → identify components and connections → extract structured data → translate to KiCad symbols and nets → validate against datasheets.\n\nFor the full methodology — component extraction, notation conventions, net mapping, subcircuit extraction, KiCad translation, and validation — read `references\u002Fpdf-schematic-extraction.md`.\n\nFor deep validation of extracted circuits against datasheets (verifying values, checking patterns, detecting errors), use the methodology in `references\u002Fschematic-analysis.md`.\n\n## Analysis Scripts\n\nThis skill includes Python scripts that extract comprehensive structured JSON from KiCad files in a single pass. Run these first, then reason about the output.\n\nRead analyzer JSON output directly rather than writing ad-hoc extraction scripts. The JSON schema has specific field names (documented below and in `references\u002Foutput-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))\"`.\n\n**When the JSON surprises you** — an AttributeError, unexpected shape, field\nreturning `None` that \"should\" have a value — stop and run `--schema` before\nwriting a second extraction attempt. It prints the exact field names and\ntypes for every top-level key:\n\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py --schema\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py --schema\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py --schema\n```\n\n**JSON field cheat sheet** — the most common mistakes when reading analyzer\noutput by hand:\n\n| What you want | Correct path and field | Common mistake |\n|---------------|-----------------------|----------------|\n| Pins on a net | `nets[\u003Cname>].pins[].component \u002F .pin_number \u002F .pin_name \u002F .pin_type` | `ref`, `pin`, `type`, `number` |\n| Net display name | `nets[\u003Cname>].display_name` — the name to show when the key is not: the decoded name of an escaped key (`A{slash}B` → `A\u002FB`), the bare name of a sheet-qualified key, or a `Ref.PinName` hint for an `__unnamed_N` net (e.g. `__unnamed_36 → U1.VBOOT`). Absent when the key is already the shown name. | Pasting a raw key (`A{slash}B`, `__unnamed_36`) into the report |\n| IC pin map | `ic_pin_analysis[]` is a **list** of IC entries; each has `.reference` and `.pins[]` with `.pin_number \u002F .pin_name \u002F .pin_type \u002F .net \u002F .connected_to[]`. Scope: `type` in `{ic, connector, crystal, oscillator}` only. | Treating it as `{ref: {...}}` or `pins[].number` |\n| Transistor pin map | `transistor_pin_analysis[]` — **separate** list for `type=transistor` (MOSFETs, BJTs, FETs), same per-entry shape as `ic_pin_analysis[]`. Use this for half-bridge \u002F gate-driver pin verification. | Looking inside `ic_pin_analysis[]` for `Q1` — transistors are not there |\n| Detected circuits | Every 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 |\n| 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'` |\n| Zone layer | `pcb.zones[].layers` (plural) is the canonical layer list. `zones[].layer` (singular) is reserved\u002FNone on multi-layer zones — always read `.layers`. | Reading `zones[].layer` and getting `None` |\n| Footprint position | `pcb.footprints[].x \u002F .y` at top level (no `.position` wrapper) | `footprints[].position.x` |\n| Per-pad net info on a footprint | `pcb.footprints[].pad_nets{pad_number: {net, pin}}` is a dict keyed by pad number. `connected_nets[]` gives the deduped list of nets touching the footprint. | `footprints[].pads[]` — that key does not exist in the output |\n| Tracks summary | `pcb.tracks` is a **dict** (the `Tracks` envelope): `{segment_count, arc_count, layer_distribution{}, width_distribution{}}`. Only `--full` populates the inner `tracks.segments[]` and `tracks.arcs[]` arrays. Segment fields: `{x1, y1, x2, y2, width, layer, net}` — `net` is an **int** id (map via top-level `nets` \u002F `net_name_to_id`). | `for t in tracks: ...` without `--full` — `tracks` is the summary dict, not a list; `seg.get(\"x\")` \u002F `seg.get(\"start\")` — wrong keys, and `.get()` defaults turn them into silent-0.0 bugs |\n| Power net routing | `pcb.power_net_routing` is a **list** of per-net entries `[{net, track_count, total_length_mm, ...}, ...]`, not a dict keyed by net. | `power_net_routing[\"VCC\"]` → TypeError |\n| 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) |\n\nThis 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\u002Foutput-schema.md` for the full schema with common extraction patterns.\n\nIn all commands below, `\u003Cskill-path>` refers to this skill's base directory (shown at the top of this file when loaded).\n\n### Schematic Analyzer\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --analysis-dir analysis\u002F\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --analysis-dir analysis\u002F --compact\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --output analysis.json  # one-off, no cache\n```\nOutputs structured JSON (~60-220KB depending on board complexity) with:\n- **Components & BOM**: inventory with reference, value, footprint, lib_id, type classification, MPN, datasheet; deduplicated BOM with quantities\n- **Nets**: full connectivity map with pin-to-net mapping, wire counts, no-connects\n- **Detected subcircuits** (pattern-matched circuits — all emitted as `findings[]` entries with matching `Det.*` detectors; use `get_findings(data, Det.POWER_REGULATORS)` etc. to fetch):\n  - Power regulators — LDO\u002Fswitching\u002Finverting topology, Vout estimation via datasheet-verified Vref lookup (~60 families) with heuristic fallback and fixed-output suffix parsing, `vref_source` (`datasheet`\u002F`lookup`\u002F`heuristic`\u002F`fixed_suffix`) and `vout_net_mismatch` fields\n  - Voltage dividers, RC\u002FLC filters (cutoff frequency), feedback networks, crystal circuits (load cap analysis, IC pin-based detection)\n  - Op-amp circuits (configuration, gain, integrator\u002Fcompensator), transistor circuits (net-name-aware load classification: motor\u002Fheater\u002Ffan\u002Fsolenoid\u002Fvalve\u002Fpump\u002Frelay\u002Fspeaker\u002Fbuzzer\u002Flamp; FET level shifter topology)\n  - Bridge circuits (H-bridge, 3-phase, cross-sheet detection), protection devices (ESD\u002FTVS), current sense, decoupling analysis\n  - Domain-specific: RF chains, RF matching networks, BMS, Ethernet (BFS PHY-to-connector tracing), HDMI\u002FDVI interfaces, memory interfaces, key matrices (net-name and topology-based), isolation barriers, addressable LED chains (WS2812\u002FSK6812\u002FAPA102), battery chargers (TP4056\u002FMCP73831\u002FBQ2404x), motor drivers (A4988\u002FTMC2209\u002FDRV8301), ESD protection coverage audit, debug interfaces (SWD\u002FJTAG with MCU tracing), power path (load switches\u002Fideal diodes\u002FUSB PD controllers), ADC signal conditioning (external ADCs + voltage references with anti-aliasing cross-ref), reset\u002Fsupervisor circuits (voltage supervisors\u002Fwatchdogs\u002FRC reset networks), clock distribution (clock generators\u002FPLLs\u002Foscillator output tracing), display\u002Ftouch interfaces (SSD1306\u002FILI9341\u002FST7789\u002FFT6236\u002FGT911), sensor fusion (IMU\u002Fenvironmental\u002Fmagnetometer with interrupt validation and bus clustering), level shifters (IC-based + discrete BSS138 with supply domain mapping), audio circuits (amplifiers\u002Fcodecs with I2S\u002Fclass-D detection), LED driver ICs (PWM\u002Fmatrix\u002Fconstant-current), RTC circuits (battery backup\u002Fcrystal pairing), LED lighting audit (current limiting validation), thermocouple\u002FRTD interfaces (MAX31855\u002FMAX31865), power sequencing validation (power tree\u002Fenable chain\u002FPG daisy chain analysis)\n- **IC pinout analysis**: pin-level connectivity, IC function classification (3-tier: library prefix, part number keywords, description fallback)\n- **Power analysis**: PDN impedance (1kHz–1GHz with MLCC parasitics), power budget, power sequencing (EN\u002FPG chains), sleep current audit (resistive paths + regulator Iq with EN detection), voltage derating, inrush estimation\n- **Design analysis**: ERC warnings, power domains, bus detection (I2C\u002FSPI\u002FUART\u002FCAN\u002FRS-485 with COPI\u002FCIPO\u002FSDI\u002FSDO), differential pairs (suffix-pair matching for USB\u002FLVDS\u002FEthernet\u002FHDMI\u002FMIPI\u002FPCIe\u002FSATA\u002FCAN\u002FRS-485), cross-domain signals (voltage equivalence), BOM optimization, test coverage, assembly complexity, USB compliance\n- **Quality checks**: annotation completeness, label validation, PWR_FLAG audit, footprint filter validation, sourcing audit, property pattern audit, generic transistor symbol detection (flags Q_NPN_*\u002FQ_PNP_*\u002FQ_NMOS_*\u002FQ_PMOS_* symbols with datasheet availability check)\n- **Structural**: MCU alternate pin summary, ground domain classification, bus topology, wire geometry, spatial clustering, pin coverage, hierarchical label validation\n\nSupports modern `.kicad_sch` (KiCad 6+) and legacy `.sch` (KiCad 4\u002F5). Hierarchical designs parsed recursively.\n\n**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.\n\n### Supplementary Data for Legacy Designs\n\nWhen `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.\n\nFor detailed parsing instructions, data recovery workflows, and a priority matrix of supplementary sources (netlist, cache library, PCB cross-reference, PDF exports), read `references\u002Fsupplementary-data-sources.md`.\n\n**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:\n\n1. **Component count** — grep for `(symbol (lib_id` blocks, subtract power symbols. Must match analyzer count exactly.\n2. **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\u002Flabels 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\u002FERC.\n3. **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:\n   - For transistors (BJT\u002FMOSFET) 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.\n   - When an MPN is specified, verify the symbol's pin-to-pad assignment against the datasheet's pinout diagram for that specific package.\n   - 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.\n   - **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?).\n4. **Net trace** — trace power rails and critical signal nets end-to-end through wires\u002Flabels. Verify the analyzer's pin list is complete for each net.\n5. **Regulator Vout** — check the `vref_source` field. `\"datasheet\"` means the Vref came from a trusted datasheet extraction and `\"lookup\"` from the datasheet-verified part table (~60 families); `\"heuristic\"` means a common reference fitted to the rail name when one lands within 10 % (else the first giving 0.5–60 V), a guess that needs manual verification. The `vout_net_mismatch` field flags estimated Vout differing >15% from the output rail name voltage.\n6. **Hierarchical connectivity** — on multi-sheet designs, verify sub-sheet connections are reflected in the net data.\n\nSee `references\u002Fschematic-analysis.md` Step 2 for the full verification checklist. If the script fails or returns unexpected results, see `references\u002Fmanual-schematic-parsing.md` for the complete fallback methodology.\n\n### PCB Layout Analyzer\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --analysis-dir analysis\u002F --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --analysis-dir analysis\u002F --proximity  # add crosstalk analysis\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --output pcb.json --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json  # one-off; cross-ref + power-rail auto-detect\n```\nOutputs structured JSON (~50-300KB depending on board complexity) with:\n- **Core**: footprint inventory (pads, courtyards, net assignments, extended attrs, schematic cross-reference), track\u002Fvia statistics, zone summaries, board outline\u002Fdimensions, routing completeness (proven from copper connectivity only with `--full`; without it, every multi-pad net has some copper)\n- **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\n- **Via analysis**: type breakdown (through\u002Fblind\u002Fmicro), annular ring checks, via-in-pad detection, BGA\u002FQFN fanout patterns, current capacity, stitching via identification, tenting\n- **Signal integrity**: per-net trace length, layer transition tracking (ground return paths), trace proximity\u002Fcrosstalk (with `--proximity`)\n- **Power & thermal**: current capacity per net, power net routing summary, ground domain identification (AGND\u002FDGND), zone stitching via density, thermal pad detection and via counting\n- **Manufacturing**: placement analysis (courtyard overlaps, edge clearance), decoupling cap distances, DFM scoring (JLCPCB standard\u002Fadvanced tier), tombstoning risk (0201\u002F0402 thermal asymmetry), thermal pad via adequacy, silkscreen documentation audit\n\nAdd `--full` to include individual track\u002Fvia 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.\n\n**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.\n\n**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 `analyze_copper_presence` findings (CP-001..CP-003) and `copper_presence_summary` show which components have zone copper on the opposite layer — use these for capacitive touch pad isolation, antenna keep-out, and thermal analysis instead of inferring copper presence from zone outlines.\n\n**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\u002Flength) for all copper-sensitive components. See `references\u002Fpcb-layout-analysis.md` → Copper-Sensitive Components for the full checklist.\n\n**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\u002Fmanual-pcb-parsing.md` for the fallback methodology.\n\n### PCB Rich Format and Assembly Checks\n\nAll PCB analysis sections now produce findings with the rich format (detector, rule_id, category, severity, confidence, summary, recommendation, report_context). Additionally, 7 new assembly\u002FDFM checks run automatically:\n\n- **FD-001**: Fiducial marker presence (>= 3 per SMD side)\n- **TE-001**: Test point coverage across signal nets\n- **OR-001**: Passive component orientation consistency\n- **SK-001**: Silkscreen text overlapping exposed pads\n- **VP-001**: Via in an SMD pad — warning when the pad's mask opening exposes it or it is untented, info when tented (--full mode)\n- **BV-001**: Via clearance from board edges (--full mode)\n- **KO-001**: Keepout zone violations\n- **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).\n\n### Cross-Domain Analysis\n\nAfter running both schematic and PCB analyzers, run the cross-domain analyzer.\nPoint `--schematic` and `--pcb` at the current run's JSON files and pass\n`--analysis-dir analysis\u002F` so the result lands inside the same run folder\nand the manifest tracks it:\n\n```\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py \\\n    --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json \\\n    --pcb analysis\u002F\u003Crun_id>\u002Fpcb.json \\\n    --analysis-dir analysis\u002F\n\n# One-off (bypasses the cache)\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py \\\n    --schematic schematic.json --pcb pcb.json --output cross_analysis.json\n```\n\nChecks: CC-001 connector current capacity, EG-001 ESD protection gaps, DA-001 decoupling adequacy, XV-001..004 schematic\u002FPCB sync (parts paired by schematic path; XV-003 footprint, XV-004 MPN). PCB JSON optional.\n\nMechanical cross-verify (PCB vs schematic geometry): `python3 \u003Cskill-path>\u002Fscripts\u002Fcross_verify.py --help`.\n\n### Connectivity Graph (--full mode)\n\nWhen `--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. **The top-level keys of `connectivity_graph` are net names themselves** — e.g., `cg['GND']`, `cg['Net-(D2-K)']`, `cg['+3V3']` — *not* a `per_net` wrapper. Each net entry shows island count, component-to-island mapping (`{component:pad: island_id}`), gap locations, and disconnected pad pairs.\n\n### Gerber & Drill Analyzer\n```bash\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py \u003Cgerber_directory\u002F> --analysis-dir analysis\u002F\n\n# One-off\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py \u003Cgerber_directory\u002F> --output gerber.json\n```\nOutputs: layer identification (X2 attributes), component\u002Fnet\u002Fpin mapping (KiCad 6+ TO attributes), aperture function classification, trace width distribution, board dimensions, drill classification (via\u002Fcomponent\u002Fmounting), layer completeness, copper-outside-outline check, pad type summary (SMD\u002FTHT ratio). Add `--full` for complete pin-to-net connectivity dump. ~10KB JSON.\n\nThe gerber analyzer produces a `findings` list with rich format findings: GR-001 missing layers, GR-002 copper outside the board outline, GR-003 drill problems, GR-004 paste aperture mismatches, GR-005 open board outlines.\n\nIf the script fails or returns unexpected results, see `references\u002Fmanual-gerber-parsing.md` for the complete fallback methodology for parsing raw Gerber\u002FExcellon files directly.\n\nAll scripts output JSON to stdout by default. Prefer `--analysis-dir analysis\u002F`\nto integrate output into the run-folder convention described in \"Analysis\nCache Convention\" below — every analyzer in a single session then co-locates\ninside the same `analysis\u002F\u003Crun_id>\u002F` folder and is tracked by the manifest.\nUse `--output file.json` only for one-off runs where you don't want the\nresult cached. Add `--compact` for single-line JSON.\n\n**Analyzer JSON is worth keeping** — these are expensive to regenerate (large\nschematics take time). `--analysis-dir` preserves every run and is the form\ndownstream tools (diff_analysis, what_if) expect. They're not worth\ncommitting to git, but don't delete them between analysis steps.\n\n### Harmonized Output Format\n\nAll analyzers produce a uniform output envelope:\n\n```json\n{\n    \"analyzer_type\": \"schematic|pcb|emc|cross_analysis|thermal|gerber|lifecycle|spice\",\n    \"schema_version\": \"1.4.0\",\n    \"summary\": {\n        \"total_findings\": 42,\n        \"by_severity\": {\"error\": 3, \"warning\": 15, \"info\": 24}\n    },\n    \"findings\": [\n        {\"rule_id\": \"...\", \"detector\": \"...\", \"severity\": \"...\", \"confidence\": \"...\", \"evidence_source\": \"...\", \"summary\": \"...\", ...}\n    ],\n    \"trust_summary\": {\n        \"total_findings\": 42,\n        \"trust_level\": \"high|mixed|low\",\n        \"by_confidence\": {\"deterministic\": 20, \"heuristic\": 18, \"datasheet_backed\": 4},\n        \"by_evidence_source\": {\"datasheet\": 4, \"topology\": 10, \"heuristic_rule\": 18, ...},\n        \"provenance_coverage_pct\": 96.5\n    }\n}\n```\n\nThe `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`.\n\nAll analyzers support `--text` (human-readable report), `--analysis-dir`\n(run-folder output, preferred) and `--output` (one JSON file). Pass only one\nJSON destination: given both, schematic and PCB write only the run folder,\nEMC writes both, and gerber, thermal and cross-analysis write only `--output`.\n\n### Stage and Audience Filtering\n\nAll analyzers support `--stage` and `--audience` flags:\n\n**Stages:** `schematic`, `layout`, `pre_fab`, `bring_up`\n**Audiences:** `designer` (default), `reviewer`, `manager`\n\n```bash\n# Show only layout-relevant findings for a reviewer\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py board.kicad_pcb --stage layout --audience reviewer --text\n\n# Manager summary of schematic review readiness\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py design.kicad_sch --audience manager --text\n\n# Pre-fab checklist for cross-domain analysis\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py -s sch.json -p pcb.json --stage pre_fab --text\n```\n\nJSON 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\u002Freviewer\u002Fmanager views. `--text` output respects both flags.\n\n### Generated Files\n\nAnalysis outputs are stored in `analysis\u002F` with timestamped run folders managed by `analysis_cache.py`. The manifest (`analysis\u002Fmanifest.json`) tracks all runs.\n\n| File Type | Location | Regenerable? | Commit to git? |\n|-----------|----------|-------------|----------------|\n| Analyzer JSON | `analysis\u002F\u003Ctimestamp>\u002F*.json` | Yes (expensive) | Configured by `track_in_git` in `.kicad-happy.json` (default: no) |\n| Manifest | `analysis\u002Fmanifest.json` | Yes | Always (tracked by default) |\n| Design review report | User-chosen path | Yes | Optional |\n\nWhen 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.\n\nSee also the `bom` skill's cleanup section for datasheets, order CSVs, and backups.\n\n### Analysis Cache Configuration\n\nThe `analysis` section in `.kicad-happy.json` controls the shared analysis output directory:\n\n```json\n{\n  \"analysis\": {\n    \"output_dir\": \"analysis\",\n    \"retention\": 0,\n    \"auto_diff\": true,\n    \"track_in_git\": false,\n    \"diff_threshold\": \"major\"\n  }\n}\n```\n\n| Field | Default | Description |\n|-------|---------|-------------|\n| `output_dir` | `\"analysis\"` | Analysis directory; relative paths resolve against the working directory |\n| `retention` | `0` | Max unpinned runs to keep. `0` = keep all (default) |\n| `auto_diff` | `true` | Auto-include delta section in design reviews |\n| `track_in_git` | `false` | When false, JSONs gitignored but manifest tracked |\n| `diff_threshold` | `\"major\"` | Severity that triggers new timestamped folder: `all` (= `minor`), `minor`, `major`, `breaking` |\n\nAll fields are optional. Missing fields use defaults.\n\n### Output JSON Schema Quick Reference\n\n**Schematic analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ninputs, compat, assessments, diagnostics, kicad_version, file_version, title_block, statistics,\nbom, components, nets, subcircuits, ic_pin_analysis, transistor_pin_analysis,\ndesign_analysis, connectivity_issues, rail_voltages\n```\nOptional (present when non-empty): `hierarchy_warning` (sub-sheet run without its root), `net_classifications`, `pdn_impedance`, `sleep_current_audit`, `power_budget`, `power_sequencing`, `bom_optimization`, `test_coverage`, `assembly_complexity`, `usb_compliance`, `inrush_analysis`, `sheets` (multi-sheet only), `missing_info`, `bom_lock`, `project_settings`\n\nKey nested structures:\n- `statistics`: `{total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}`\n- `bom[]`: `{reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}`\n- `components[]`: `{reference, value, footprint, lib_id, lib_name, type, category, mpn, datasheet, dnp, in_bom, parsed_value, ...}`\n- `nets{net_name}`: `{pins[], wires, labels[], ...}` — each pin: `{component, pin_number, pin_name, pin_type, ...}` (NOT `ref` or `pin`)\n- `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.\n- **Detected subcircuits live in `findings[]`** — power regulators, voltage dividers, RC\u002FLC filters, feedback networks, opamp\u002Ftransistor\u002Fbridge\u002Fcrystal circuits, current sense, decoupling, protection, buzzer\u002Fspeaker, Ethernet\u002FHDMI\u002Fmemory interfaces, RF chains\u002Fmatching, 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.\n\n**PCB analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ninputs, compat, assessments, diagnostics, kicad_version, file_version, statistics, layers, setup,\nnets, net_name_to_id, board_outline, component_groups, footprints,\ntracks, vias, zones, keepout_zones, connectivity, net_lengths\n```\nOptional: `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`, `thermal_pad_scan`, `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).\n\nKey nested structures:\n- `net_lengths` is a **list** (not dict): `[{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...]` sorted by length descending\n- `power_net_routing` is a **list**: `[{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]`\n- `footprints[]`: `{reference, value, footprint, layer, pad_nets{}, sch_path, sheetname, sheetfile, connected_nets[], ...}`\n- `statistics`: `{footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}`\n\n**Gerber analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ndirectory, generator, layer_count, statistics, completeness, alignment,\ndrill_classification, pad_summary, board_dimensions, gerbers, drills\n```\n\n**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\u002F` 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.\n\n**Before starting the workflow below for a design review:** read `references\u002Freport-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.\n\n1. **Scan the project directory** for `.kicad_sch`, `.kicad_pcb`, `.kicad_pro`, gerber directories, and `.net`\u002F`.xml` netlist files.\n2. **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.\n3. **Run the core analyzers.** If the schematic exists, run `analyze_schematic.py`. If the PCB exists, run `analyze_pcb.py --full --schematic \u003Cschematic JSON>` after it (SW-003 needs the schematic for the pad loop). If gerbers exist, run `analyze_gerbers.py` in parallel.\n4. **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\u002FPCB sync).\n5. **Run EMC pre-compliance** — when both schematic and PCB analysis exist, run `python3 \u003Cemc-skill-path>\u002Fscripts\u002Fanalyze_emc.py --schematic sch.json --pcb pcb.json` (the script lives in the `emc` skill — not under this skill's `\u003Cskill-path>`). 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.\n6. **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: `python3 \u003Cspice-skill-path>\u002Fscripts\u002Fsimulate_subcircuits.py sch.json`. This validates filter frequencies, divider ratios, opamp gains, and more against actual simulation results. SPICE takes \u003C1 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, run `python3 \u003Cspice-skill-path>\u002Fscripts\u002Fextract_parasitics.py pcb.json --output parasitics.json` (needs the `--full` PCB JSON) and pass `--parasitics parasitics.json` — a path argument, not a bare flag — to add trace R and via L to low-pass RC-filter benches (other benches ignore it). 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\u002FC3\"`), `status` (`pass`\u002F`warn`\u002F`fail`\u002F`info`\u002F`skip`), `expected` (dict of metric values), `simulated` (dict of measured values), `delta` (dict of error percentages).\n7. **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.\n8. **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 \u002F no network \u002F no MPNs].\"\n9. **Read the `.kicad_pro`** project file directly (it's JSON) for design rules, net classes, and DRC\u002FERC settings.\n10. **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.\n11. **Verify each output** against the raw files and datasheets before using the data in your report.\n12. **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\u002Freport-generation.md` for the report template.\n13. **Disclose all review gaps explicitly** — if thermal, lifecycle, gerber, datasheet extraction, or prior-review delta were not performed, add a short \"Not performed \u002F limits\" section to the report instead of omitting them silently.\n\nThe 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.\n\n### Analysis Depth\n\nDefault 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:\n\n- **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.\n- **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\u002Fsection numbers when reporting verification results.\n- **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.\n- **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.\n\n### Datasheet Acquisition\n\nBefore the Deep Review pass, check availability: the extraction cache\n(`datasheets\u002Fextracted\u002F`) is the fast path; PDFs on disk\n(`datasheets\u002F`) are the fallback — read them directly. If parts have\nneither, offer to sync datasheets (digikey \u002F lcsc \u002F mouser \u002F\nelement14 skills) before reviewing without them. Extractions carry a\nquality flag — low-quality facts come back flagged, not hidden;\ndecide whether to trust them or re-read the PDF.\n\nDatasheets 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.\n\n**Automated sync (preferred):** Run datasheet sync scripts early in the workflow. They download datasheets for all components with MPNs into a shared `datasheets\u002F` 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.\n\n```bash\npython3 \u003Cdigikey-skill-path>\u002Fscripts\u002Fsync_datasheets_digikey.py \u003Cfile.kicad_sch>\npython3 \u003Clcsc-skill-path>\u002Fscripts\u002Fsync_datasheets_lcsc.py \u003Cfile.kicad_sch>\npython3 \u003Celement14-skill-path>\u002Fscripts\u002Fsync_datasheets_element14.py \u003Cfile.kicad_sch>\npython3 \u003Cmouser-skill-path>\u002Fscripts\u002Fsync_datasheets_mouser.py \u003Cfile.kicad_sch>\n```\n\nDigiKey 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).\n\n**Check for existing datasheets:** Before downloading, look for:\n- `\u003Cproject>\u002Fdatasheets\u002F` with `manifest.json` (from a previous sync)\n- `\u003Cproject>\u002Fdocs\u002F` or `\u003Cproject>\u002Fdocumentation\u002F`\n- PDF files in the project directory whose names contain MPNs\n- `Datasheet` property URLs embedded in the KiCad symbols\n\n**Fallback methods when automated sync isn't available or misses parts:**\n1. Use the `Datasheet` property URL from the schematic symbol — many KiCad libraries include direct PDF links\n2. Use the `digikey` skill to search by MPN and download individual datasheets\n3. Use web search to find the manufacturer's datasheet page\n4. **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.\"\n\n**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.\n\n```bash\npython3 -c \"import sys; sys.path.insert(0, '\u003Cdatasheets-skill-path>\u002Fscripts'); from datasheet_page_selector import suggest_pages; s = suggest_pages('\u003Cpdf_path>', '\u003Cmpn>', '\u003Ccategory>'); print(s.pages, s.reasons)\"\n```\n\nAfter 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\u002Fextracted\u002F` (named by the cache manager, listed in `manifest.json`) and reused across reviews. The **`datasheets` skill** owns the full extraction pipeline (schema, page selection, scoring rubric, consumer API) — see `skills\u002Fdatasheets\u002FSKILL.md` and its reference guides.\n\n**What to extract from each datasheet** (note page\u002Fsection\u002Ffigure\u002Fequation numbers for citations):\n- Pin function table (pin number → name → function)\n- Absolute maximum ratings (voltage, current, temperature — including max continuous current through VCC\u002FGND pins, which constrains inrush)\n- Recommended application circuit and required external components\n- Required component values (and the equations that derive them)\n- Thermal characteristics\n\n**For passives:** While individual resistor\u002Fcapacitor 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.\n\n**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\u002Fcommunity 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\u002Fsection\u002Ffigure number in your report so the designer can confirm your work.\n\n### Schematic + PCB Cross-Reference\n\nWhen both files exist, cross-reference them. This catches the most expensive bugs — swapped pins, missing nets, and footprint mismatches pass DRC\u002FERC but produce non-functional boards.\n\n1. **Component count**: Schematic count (excluding power symbols) vs PCB footprint count.\n2. **Net consistency**: Verify schematic net names appear in PCB net declarations. Missing nets suggest incomplete routing or un-synced changes.\n3. **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:\n   - Custom\u002Fcommunity library symbols (may not match datasheet pinout)\n   - Multi-unit symbols (op-amps, gate arrays) — unit-to-pin assignment errors\n   - QFN\u002FBGA packages — pad numbering mistakes\n   - Transistors without MPNs — pinout ambiguity (see verification step 3)\n   - Polarized components — anode\u002Fcathode orientation\n   - Connectors — pin 1 orientation\n4. **Footprint match**: Schematic `Footprint` property vs actual PCB footprint (e.g., SOT-23 vs SOT-23-5).\n5. **DNP consistency**: DNP components in schematic should not have routing on PCB.\n6. **Value\u002FMPN consistency**: Values and MPNs match between schematic and PCB properties.\n\nThe PCB analyzer's `sch_path`, `sheetname`, and `sheetfile` fields in each footprint enable automated cross-referencing.\n\n### Diff-Aware Design Comparison\n\nCompare 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\u002Fdiff-analysis.md`.\n\n```bash\n# Compare two schematic analysis outputs (JSON to stdout)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json\n\n# Human-readable text output\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --text\n\n# Write to file, custom threshold (ignore \u003C2% deltas)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --output diff.json --threshold 2.0\n\n# Ignore small percentage changes (e.g., rounding noise)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --threshold 5.0 --text\n```\n\nAuto-detects analyzer type (schematic, PCB, EMC, SPICE). Reports:\n- **Components**: new, removed, value\u002Ffootprint\u002FMPN changes\n- **Signal analysis**: parameter shifts per detection type, driven by `detection_schema.SCHEMAS` identity and value fields\n- **BOM**: added\u002Fremoved line items, quantity changes\n- **Connectivity\u002FERC**: new\u002Fresolved single-pin nets, floating nets, multi-driver nets, ERC warnings\n- **EMC findings**: new\u002Fresolved findings with severity, risk score delta, per-net score changes\n- **SPICE results**: status transitions (pass->fail regressions, fail->pass fixes), Monte Carlo concern changes\n- **Severity classification**: `none` (no changes), `minor` (statistics only), `major` (component\u002Fsignal\u002Ffinding changes), `breaking` (SPICE regressions, new EMC `error` findings, new ERC warnings)\n\nAlso used programmatically by `analysis_cache.should_create_new_run()` to decide whether new outputs warrant a new timestamped run folder.\n\n### Thermal Hotspot Estimation\n\nEstimates 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\".\n\n```bash\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py \\\n    -s analysis\u002F\u003Crun_id>\u002Fschematic.json \\\n    -p analysis\u002F\u003Crun_id>\u002Fpcb.json \\\n    --analysis-dir analysis\u002F\n\n# Human-readable text report\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py -s schematic.json -p pcb.json --text\n\n# Custom ambient temperature (default: 25°C), one-off output file\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py -s schematic.json -p pcb.json --ambient 40 -o thermal.json\n```\n\nModels 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\u002FW, QFN-5x5: 25°C\u002FW, etc.) and is corrected for PCB thermal vias and copper pour. Rules:\n\n| Rule | Condition | Severity |\n|------|-----------|----------|\n| TS-001 | Tj exceeds absolute maximum | error |\n| TS-002 | Tj within 15°C of absolute maximum | error |\n| TS-003 | Tj > 85°C (may affect nearby passives) | warning |\n| TS-004 | P > 0.5W with no thermal vias | warning |\n| TS-005 | Significant power, within safe limits | info |\n| TP-001 | MLCC within 10mm of hot component | info |\n| TP-002 | Electrolytic cap within 10mm of hot component | warning |\n\nThermal 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).\n\n### Interactive \"What-If\" Parameter Sweep\n\nInstantly 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\u002Fwhat-if.md`](references\u002Fwhat-if.md).\n\n```bash\n# Single value change\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --text\n\n# Sweep: comma list or log range\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=1k,2.2k,4.7k,10k --text\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=1k..100k:10 --text\n\n# Tolerance corner analysis (±5% worst-case)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k+-5% C3=100n+-10% --text\n\n# Inverse solver, E-series snapping (divider target = Vout\u002FVin, e.g. 3.3 V of 5 V; filter = Hz)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json --fix 'voltage_dividers[0]' --target 0.66 --text\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json --fix 'rc_filters[0]' --target 1000 --text\n\n# EMC impact preview\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json C3=1u --emc --text\n\n# SPICE re-simulation on affected subcircuits\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --spice --text\n\n# Export patched JSON for further analysis (EMC, thermal, diff)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --output patched.json\n```\n\nPatches 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\u002Fafter 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.\n\n### Findings Summary\n\nSummarises 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\u002Fmanifest.json`.\n\n```bash\n# Top findings from the current run (default: top 20)\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F\n\n# Limit to the top 10 error findings\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --top 10 --severity error\n\n# JSON output for programmatic consumption\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --json\n\n# Summarise a specific run by ID\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --run \u003Crun_id>\n```\n\nFlags: `--top N` (default 20), `--severity` (filter to `error`\u002F`warning`\u002F`info`; `critical`\u002F`high` mean `error`), `--run` (explicit run ID instead of latest), `--json` (machine-readable output); also `--confidence`, `--evidence-source`, `--by-confidence`, `--only-deterministic`, `--no-deep-review` (see `--help`).\n\n### Component Lifecycle & Temperature Audit\n\nQueries 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.\n\n```bash\n# Basic lifecycle check\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json\n\n# With temperature range validation (preset or custom)\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --temp-range industrial\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --temp-range=\"-40,105\"\n\n# Query specific distributors only\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --only digikey,lcsc\n\n# Search for replacement parts when EOL\u002FNRND found\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --suggest-alternatives\n\n# Save results\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --output lifecycle.json\n```\n\nReads 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\u002F70°C), `industrial` (-40\u002F85°C), `extended` (-40\u002F105°C), `automotive` (-40\u002F125°C), `military` (-55\u002F125°C). Also checks datasheet extraction cache for temperature data before making API calls.\n\nThe lifecycle audit produces rich format findings: LC-001 (obsolete\u002Fdiscontinued), 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). When `--lifecycle` is NOT passed (the default), `analyze_schematic.py` emits an `LC-007` info finding noting that the audit was skipped — keeps the gap explicit in the report's findings list instead of being a silent omission.\n\n**Requires network access** — unlike the core analyzers, this script calls distributor APIs. Same environment variables as the distributor skills (DIGIKEY_CLIENT_ID\u002FSECRET, MOUSER_SEARCH_API_KEY, ELEMENT14_API_KEY). LCSC requires no credentials.\n\n### Schematic Analyzer Rule IDs\n\nAll schematic rule findings appear in `findings[]`. The following rule IDs are produced by the schematic analyzer:\n\n| Rule | Detector | Condition | Severity |\n|------|----------|-----------|----------|\n| SS-001 | `audit_sourcing_gate` | MPN coverage \u003C 50% | error |\n| SS-002 | `audit_sourcing_gate` | MPN coverage 50–80% | warning |\n| SS-003 | `audit_sourcing_gate` | MPN coverage 80–100% | info |\n| NT-001 | `analyze_connectivity` | Single-pin net: signal pin | warning |\n| NT-001 | `analyze_connectivity` | Single-pin net: power_out or passive pin | info |\n| RS-001 | `audit_rail_sources` | Rail has no declared source (no power_out pin, no PWR_FLAG, no bridged-jumper or regulator output) | warning |\n| RS-002 | `audit_rail_sources` | Rail depends on user closing an open jumper | error |\n| RS-003 | `audit_rail_sources` | Rail sourced indirectly via a bridged-by-default solder jumper or ferrite — functional but consider adding PWR_FLAG | info |\n| LB-001 | `detect_label_aliases` | Net has >= 2 distinct global\u002Fhierarchical labels (power nets excluded) | info |\n| PP-001 | `audit_power_pin_dc_paths` | IC power_in pin reaches a rail only through a capacitor (2-hop BFS) | error |\n| SP-001 | `detect_shorted_two_pin_components` | Two-pin passive or diode with both pins on one net (jumpers, net ties, 0R, DNP excluded); >= 5 on one net collapse into one net-level finding | warning |\n\nSS-001 is a pre-fab blocker — an `error` finding that should be resolved before ordering. NT-001 severity depends on pin type: signal pins (digital I\u002FO, bidirectional) are `warning`; power_out and passive pins are `info`. RS-001 is reserved for the \"no source at all\" case (warning); the softer \"sourced via bridged jumper \u002F ferrite\" case has its own rule_id RS-003 (info) so reviewers and CI gates can filter the two independently. 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. PP-001 demotes to `info` on module-internal LDO rails (`VDDPLL_*`, `VDDA_INT_*`, `VDDCORE_*`, `VCAP`, `VDDREG`) where decoupling-only is the correct topology.\n\n## Deep Review Pass\n\nAfter the analyzers have run, perform the Deep Review pass: a per-IC\ncomparison of actual usage against datasheet requirements. The\nanalyzers provide facts; this pass is where the judgment happens.\n\nFor each IC in the design:\n\n1. Pull its datasheet facts — extraction cache first\n   (`datasheets\u002Fextracted\u002F\u003Csanitized_mpn>.json`), PDF fallback (read it\n   directly). If neither exists, say \"\u003CREF> unverified — no datasheet\n   available\" in the review text, not in deep_review.json, and move on.\n2. Compare against actual usage in the analyzer JSON: supply voltages\n   vs ratings, pin functions vs connections, required externals\n   (inductors, caps, resistors) vs what the schematic has, thermal\n   context. Derive the checks from the datasheet — every part has\n   its own.\n3. Where a limit needs computing, write a disposable helper script\n   under `analysis\u002Fhelpers\u002F` that reads the analyzer JSON and prints\n   the numbers. Cite script + result as evidence.\n4. Record findings in `analysis\u002Fdeep_review.json` (shape:\n   `\u003Cskill-path>\u002Freview\u002Fschemas\u002Fdeep_review.schema.json`). Every\n   finding needs an evidence block: at least one design anchor\n   (component\u002Fnet\u002Fpin) and at least one source (datasheet quote\n   and\u002For computation).\n\nThen check interacting pairs: shared rails (sequencing, combined load), bus partners (voltage levels, pull-up ownership), thermal neighbors. Freestyle digging is encouraged — follow what looks wrong.\n\nValidate before reporting:\n\n```bash\npython3 \u003Cskill-path>\u002Freview\u002Fscripts\u002Fdeep_review_gate.py \\\n    analysis\u002Fdeep_review.json --analysis-dir analysis\u002F\n```\n\nThe gate verifies citations, stamps finding_ids, and moves failures\nto `quarantined[]` with reasons. Fix or accept quarantined entries;\nthe report renders them as unverified claims.\n\nRe-review: if `analysis\u002Fdeep_review.json` already exists from a prior\nreview, copy it aside first and open the new pass with a diff —\nreport fixed \u002F still-open \u002F new in the Previous Review Delta section:\n\n```bash\ncp analysis\u002Fdeep_review.json analysis\u002Fdeep_review.prev.json\n# ... run the pass, then the gate ...\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py \\\n    analysis\u002Fdeep_review.prev.json analysis\u002Fdeep_review.json --text\n```\n\nBig BOM: chunk by subsystem, or fan out per IC-group with subagents. See `references\u002Fdeep-review.md` for comparison heuristics per part class, pair-check patterns, and helper-script conventions. `analysis\u002Fdesign_context.json` (if present) steers priorities — e.g. automotive tightens derating attention. Optional; never block on it.\n\n## Reference Files\n\nDetailed methodology and format documentation lives in reference files. Read these as needed — they provide deep-dive content beyond what the scripts output automatically.\n\n| Reference | Lines | When to Read |\n|-----------|-------|-------------|\n| `deep-review.md` | 192 | Deep Review pass: per-part-class comparison heuristics, pair checks, helper-script conventions, fan-out |\n| `schematic-analysis.md` | 1167 | Deep schematic review: datasheet validation, design patterns, error taxonomy, tolerance stacking, GPIO audit, motor control, battery life, supply chain |\n| `pcb-layout-analysis.md` | 447 | Advanced PCB: impedance calculations, differential pairs, return paths, copper balance, edge clearance, copper-sensitive components (capacitive touch, antennas), custom analysis scripts |\n| `output-schema.md` | 347 | Full analyzer JSON schema with field names, types, and common extraction patterns |\n| `file-formats.md` | 382 | Manual file inspection: S-expression structure, field-by-field docs for all KiCad file types, version detection |\n| `gerber-parsing.md` | 761 | Gerber\u002FExcellon format details, X2 attributes, analysis techniques |\n| `pdf-schematic-extraction.md` | 315 | PDF schematic analysis: extraction workflow, notation conventions, KiCad translation |\n| `supplementary-data-sources.md` | 288 | Legacy KiCad 5 data recovery: netlist parsing, cache library, PCB cross-reference |\n| `net-tracing.md` | 181 | Manual net tracing: coordinate math, Y-axis inversion, rotation transforms |\n| `manual-schematic-parsing.md` | 291 | Fallback when schematic script fails |\n| `manual-pcb-parsing.md` | 459 | Fallback when PCB script fails |\n| `manual-gerber-parsing.md` | 648 | Fallback when Gerber script fails |\n| `report-generation.md` | 700 | Report template (critical findings at top), analyzer output field reference (schematic\u002FPCB\u002Fgerber), severity definitions, writing principles, domain-specific focus areas, known analyzer limitations |\n| `standards-compliance.md` | 638 | IPC\u002FIEC standards tables: conductor spacing (IPC-2221A Table 6-1), current capacity (IPC-2221A\u002FIPC-2152), annular rings, hole sizes, impedance, via protection (IPC-4761), creepage\u002Fclearance (ECMA-287\u002FIEC 60664-1). Consider for all boards; auto-trigger for professional\u002Findustrial designs, high voltage, mains input, or safety isolation. |\n| `oshwa-certification.md` | 89 | OSHWA open-source hardware certification readiness: editable KiCad sources, public documentation, licensing, version registration, certification-mark use. Read when the user asks about OSHWA certification or an open-source hardware release — a documentation\u002Flicensing audit with explicit approval gates, not an electrical check |\n| `design-intent.md` | 123 | Design intent resolution, target market \u002F certification \u002F power constraints that gate findings by context |\n| `diff-analysis.md` | 364 | How `diff_analysis.py` compares two analyzer runs and emits severity-ranked change reports |\n| `what-if.md` | 517 | How `what_if.py` patches component values, recalculates derived fields, and suggests fixes for feedback dividers \u002F crystal load caps \u002F cap derating |\n| `config-reference.md` | 405 | `.kicad-happy.json` schema — project config for analysis cache, suppressions, design intent, risk scoring |\n| `datasheet-verification.md` | 319 | Automated cross-check of schematic connections against structured datasheet extractions (pin voltage, required externals, decoupling adequacy) |\n\nFor script internals, data structures, signal analysis patterns, and batch test suite documentation, see `scripts\u002FREADME.md`.\n\n## File Types Quick Reference\n\n| Extension | Format | Purpose |\n|---|---|---|\n| `.kicad_pro` | JSON | Project settings, net classes, DRC\u002FERC severity, BOM fields |\n| `.kicad_sch` | S-expr | Schematic sheet (symbols, wires, labels, hierarchy) |\n| `.kicad_pcb` | S-expr | PCB layout (footprints, tracks, vias, zones, board outline) |\n| `.kicad_sym` | S-expr | Symbol library (schematic symbols with pins, graphics) |\n| `.kicad_mod` | S-expr | Single footprint (in `.pretty\u002F` directory) |\n| `.kicad_dru` | Custom | Custom design rules (DRC constraints) |\n| `fp-lib-table` \u002F `sym-lib-table` | S-expr | Library path tables |\n| `.sch` \u002F `.lib` \u002F `.dcm` | Legacy | KiCad 5 schematic, symbol library, descriptions |\n| `.net` \u002F `.xml` | S-expr\u002FXML | Netlist export, BOM export |\n| `.gbr` \u002F `.g*` \u002F `.drl` | Gerber\u002FExcellon | Manufacturing files (copper, mask, silk, outline, drill) |\n\nFor version detection and detailed field-by-field format documentation, read `references\u002Ffile-formats.md`. On Flatpak KiCad installs `kicad-cli` (native DRC\u002FERC reports, file exports) is not on PATH — invoke it as `flatpak run --command=kicad-cli org.kicad.KiCad \u003Cargs>`; its sandbox can't read host `\u002Ftmp`, so write exports\u002Fnetlists under the project directory (or elsewhere under `$HOME`) instead.\n\n## Analysis Strategies\n\n### Deep Schematic Analysis\n\nFor 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\u002Fschematic-analysis.md`. Use this reference whenever the user asks to review, validate, or analyze a schematic in depth.\n\n**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.\n\n### Deep PCB Analysis\n\nFor 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\u002Fpcb-layout-analysis.md`.\n\nMost 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.\n\n### Design Intent\n\nFor 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\u002Fdesign-intent.md`. Check the `design_intent` object in analysis output to understand the design context.\n\n### Probing Analyzer JSON\n\nDuring 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:\n\n**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.\n\n- Bad: `[Bash] python3 -c \"import json; d = json.load(open('analysis\u002F...\u002Fschematic.json')); print([...])\"` with no surrounding prose.\n- Good: \"Checking whether U3's EN pin is tied to +BATT directly or through a divider.\" then the probe.\n- Good: \"Verifying the detected TPS61023 topology matches the datasheet (buck-boost expected).\" then the probe.\n\nThe narrative matters most for probes that investigate *why* something looks wrong — those are the moments a user loses context fastest.\n\n**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.\n\n- 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.\n- Before `min()` \u002F `max()`, check non-empty: `min([])` raises `ValueError: min() iterable argument is empty`. Use `min(items, default=None)` or guard with `if items:`.\n- Use `.get(\"key\", default)` not `[\"key\"]` when a section may be absent (many sections are optional based on what the analyzer found).\n- `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.\n- 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\", \"\")`.\n- Pads\u002Fcomponents with missing data: `pad.get(\"abs_x\")` can be `None`; guard before arithmetic.\n\nSmall investment, much lower friction.\n\nFor probing the raw `.kicad_sch` \u002F `.kicad_pcb` files themselves (not the analyzer JSON), use `\u003Cskill-path>\u002Fscripts\u002Fkicad_core\u002Fsexp.py`: `parse(text)` and `parse_file(path)` return the document as nested Python lists; `find_all(node, kw)`, `find_first(node, kw)`, and `get_value(node, kw)` navigate it.\n\n### Quick Review Checklists\n\n**Schematic** — verify: decoupling caps on every IC VCC\u002FGND 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\u002FPG), adequate bulk capacitance.\n\n**PCB** — verify: power trace widths for current (IPC-2221), via current capacity, creepage\u002Fclearance for high voltage, decoupling cap proximity to IC power pins, continuous ground plane (no splits under signals), controlled impedance traces (USB\u002FDDR), 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\u002FDFN 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\u002Ftransistors\u002Fconnectors (catches library footprint pin numbering errors that are invisible to DRC\u002FERC — the most dangerous class of PCB bug). Consider `references\u002Fstandards-compliance.md` for IPC\u002FIEC standard values — conductor spacing and current capacity are relevant for most boards; creepage\u002Fclearance and via protection apply to mains-connected or safety-isolated designs.\n\n**Common bugs (ranked by board-killing potential)**: swapped IC pins (library symbol vs datasheet pinout — invisible to DRC\u002FERC), 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).\n\n### Report Generation\n\nWhen producing a design review report, read `references\u002Freport-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\u002Fpower\u002Fdesign 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.\n\n### Design Comparison\nWhen comparing two designs, diff: component counts\u002Ftypes, net classes\u002Fdesign rules, track widths\u002Fvia sizes, board dimensions\u002Flayer count, power supply topology, KiCad version differences.\n\n## Security Architecture\n\nAll analysis scripts process untrusted input (user-provided KiCad files,\nthird-party PDF datasheets, distributor API responses). The parsing architecture\nmitigates prompt injection and code execution risks:\n\n- **Deterministic parsers**: S-expression files (`.kicad_sch`, `.kicad_pcb`) are\n  parsed by a dedicated recursive-descent parser (`kicad_core\u002Fsexp.py`) — not\n  `eval()`, `exec()`, or any code execution primitive. The parser produces\n  Python lists\u002Fstrings only.\n- **Structured JSON boundary**: All analyzer output is structured JSON with a\n  fixed schema. External content (component values, net names, datasheet text)\n  is treated as data fields, never as instructions or code.\n- **PDF processing**: Datasheet PDFs are processed by `pdftotext` (external\n  binary, list-based args — no shell injection) and page content is passed to\n  the LLM for structured extraction. Extracted data is validated against a\n  5-dimension quality rubric before caching.\n- **No shell commands from input**: No analyzer constructs shell commands from\n  file content. Subprocess calls use list-based arguments exclusively.\n- **Read-only analysis**: Analysis scripts never modify input files. The BOM\n  write-back scripts do write when run; `--dry-run` previews the change.\n- **Distributor API scope**: Network requests are limited to known distributor\n  APIs (DigiKey, Mouser, LCSC, element14) for datasheet downloads and component\n  lookups. Only MPNs are sent — no design data leaves the local machine.\n","# KiCad Project Analysis Skill\n\n## Related Skills\n\n| Skill | Purpose |\n|-------|---------|\n| `bom` | BOM extraction, enrichment, ordering, and export workflows |\n| `digikey` | Search DigiKey for parts (prototype sourcing) |\n| `mouser` | Search Mouser for parts (secondary prototype source) |\n| `lcsc` | Search LCSC for parts (production sourcing, JLCPCB) |\n| `element14` | Search Newark\u002FFarnell\u002Felement14 (international sourcing, reliable datasheets) |\n| `jlcpcb` | PCB fabrication & assembly ordering |\n| `pcbway` | Alternative PCB fabrication & assembly |\n| `spice` | SPICE simulation verification of detected subcircuits |\n| `emc` | EMC pre-compliance risk analysis — consumes schematic + PCB analyzer output |\n\n**Handoff guidance:** Use this skill to parse schematics\u002FPCBs and extract structured data. Hand off to `bom` for BOM enrichment, pricing, and ordering. Hand off to `digikey`\u002F`mouser`\u002F`lcsc`\u002F`element14` for part searches and datasheet fetching. Hand off to `jlcpcb`\u002F`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.\n\n**Before analysis:** When the user asks to analyze or review a KiCad project, check whether a `datasheets\u002F` 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.\n\n**If you see a `DS-001` finding in the analyzer output** (severity `error`, detector `audit_datasheet_coverage`), the review cannot make any verified claim. Stop and either (a) run the datasheet sync via `digikey` \u002F `mouser` \u002F `lcsc` \u002F `element14` (whichever has credentials\u002Fstock), (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.\n\n## Design Review Contract\n\nWhen 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:\n\n1. Read the full workflow in this `SKILL.md`, not just the analyzer command sections.\n2. Read `references\u002Freport-generation.md` before writing the report.\n3. Run every applicable analyzer for the files present in the project, then say explicitly which ones were and were not run.\n4. Perform raw-file and datasheet cross-verification before claiming anything is \"verified\".\n5. Triage likely analyzer false positives before elevating them into blockers.\n6. If a required step could not be done, state it as a review gap, not as silent omission.\n\nTreat this as the minimum bar. Analyzer JSON alone is not the final review.\n\n### Minimum Review Checklist\n\nFor a full design review, explicitly account for each item below in the report:\n\n- `datasheets\u002F` present, synced, or verification gap stated\n- `analyze_schematic.py`\n- `analyze_pcb.py --full --schematic`\n- `cross_analysis.py`\n- `analyze_emc.py`\n- SPICE simulation when any simulator is installed\n- `analyze_thermal.py` when both schematic and PCB JSON exist\n- `analyze_gerbers.py` when fabrication outputs exist\n- lifecycle audit when network access and MPN coverage allow it\n- prior review \u002F prior run delta check\n- raw schematic\u002FPCB spot-verification elevated to full verification for critical parts\n- explicit report sections for blockers, verification basis, false positives, and skipped analyses\n\nIf an item is not applicable, say why. If it was skipped, say why. If it failed, say how that limits confidence.\n\n### Common Review Failure Modes\n\nThese are the failure modes this contract is meant to prevent:\n\n- Stopping after schematic + PCB + EMC output and calling it a complete review\n- Reporting analyzer findings without checking whether they are expected layout artifacts\n- Claiming \"verified\" without direct datasheet evidence or structured extraction evidence\n- Omitting thermal, lifecycle, prior-review delta, or gerber checks without disclosure\n- Writing a report that lacks a verdict, blockers table, verification basis, or skipped-analysis notes\n- Reading only the first part of this skill and missing the design-review workflow later in the file\n\n## PDF Schematic Analysis\n\nThis skill also handles **PDF schematics** — reference designs, dev board schematics, eval board docs, application notes, and datasheet typical-application circuits. Common use cases:\n\n- Analyze a manufacturer's reference design to understand the circuit\n- Extract a subcircuit (power supply, USB interface, sensor front-end) to incorporate into your own KiCad design\n- Compare a PDF reference design against your own schematic\n- Extract a full BOM from a PDF schematic\n- Validate component values in a PDF against current datasheets\n\n**Workflow:** Read the PDF pages visually → identify components and connections → extract structured data → translate to KiCad symbols and nets → validate against datasheets.\n\nFor the full methodology — component extraction, notation conventions, net mapping, subcircuit extraction, KiCad translation, and validation — read `references\u002Fpdf-schematic-extraction.md`.\n\nFor deep validation of extracted circuits against datasheets (verifying values, checking patterns, detecting errors), use the methodology in `references\u002Fschematic-analysis.md`.\n\n## Analysis Scripts\n\nThis skill includes Python scripts that extract comprehensive structured JSON from KiCad files in a single pass. Run these first, then reason about the output.\n\nRead analyzer JSON output directly rather than writing ad-hoc extraction scripts. The JSON schema has specific field names (documented below and in `references\u002Foutput-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))\"`.\n\n**When the JSON surprises you** — an AttributeError, unexpected shape, field\nreturning `None` that \"should\" have a value — stop and run `--schema` before\nwriting a second extraction attempt. It prints the exact field names and\ntypes for every top-level key:\n\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py --schema\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py --schema\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py --schema\n```\n\n**JSON field cheat sheet** — the most common mistakes when reading analyzer\noutput by hand:\n\n| What you want | Correct path and field | Common mistake |\n|---------------|-----------------------|----------------|\n| Pins on a net | `nets[\u003Cname>].pins[].component \u002F .pin_number \u002F .pin_name \u002F .pin_type` | `ref`, `pin`, `type`, `number` |\n| Net display name | `nets[\u003Cname>].display_name` — the name to show when the key is not: the decoded name of an escaped key (`A{slash}B` → `A\u002FB`), the bare name of a sheet-qualified key, or a `Ref.PinName` hint for an `__unnamed_N` net (e.g. `__unnamed_36 → U1.VBOOT`). Absent when the key is already the shown name. | Pasting a raw key (`A{slash}B`, `__unnamed_36`) into the report |\n| IC pin map | `ic_pin_analysis[]` is a **list** of IC entries; each has `.reference` and `.pins[]` with `.pin_number \u002F .pin_name \u002F .pin_type \u002F .net \u002F .connected_to[]`. Scope: `type` in `{ic, connector, crystal, oscillator}` only. | Treating it as `{ref: {...}}` or `pins[].number` |\n| Transistor pin map | `transistor_pin_analysis[]` — **separate** list for `type=transistor` (MOSFETs, BJTs, FETs), same per-entry shape as `ic_pin_analysis[]`. Use this for half-bridge \u002F gate-driver pin verification. | Looking inside `ic_pin_analysis[]` for `Q1` — transistors are not there |\n| Detected circuits | Every 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 |\n| 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'` |\n| Zone layer | `pcb.zones[].layers` (plural) is the canonical layer list. `zones[].layer` (singular) is reserved\u002FNone on multi-layer zones — always read `.layers`. | Reading `zones[].layer` and getting `None` |\n| Footprint position | `pcb.footprints[].x \u002F .y` at top level (no `.position` wrapper) | `footprints[].position.x` |\n| Per-pad net info on a footprint | `pcb.footprints[].pad_nets{pad_number: {net, pin}}` is a dict keyed by pad number. `connected_nets[]` gives the deduped list of nets touching the footprint. | `footprints[].pads[]` — that key does not exist in the output |\n| Tracks summary | `pcb.tracks` is a **dict** (the `Tracks` envelope): `{segment_count, arc_count, layer_distribution{}, width_distribution{}}`. Only `--full` populates the inner `tracks.segments[]` and `tracks.arcs[]` arrays. Segment fields: `{x1, y1, x2, y2, width, layer, net}` — `net` is an **int** id (map via top-level `nets` \u002F `net_name_to_id`). | `for t in tracks: ...` without `--full` — `tracks` is the summary dict, not a list; `seg.get(\"x\")` \u002F `seg.get(\"start\")` — wrong keys, and `.get()` defaults turn them into silent-0.0 bugs |\n| Power net routing | `pcb.power_net_routing` is a **list** of per-net entries `[{net, track_count, total_length_mm, ...}, ...]`, not a dict keyed by net. | `power_net_routing[\"VCC\"]` → TypeError |\n| 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) |\n\nThis 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\u002Foutput-schema.md` for the full schema with common extraction patterns.\n\nIn all commands below, `\u003Cskill-path>` refers to this skill's base directory (shown at the top of this file when loaded).\n\n### Schematic Analyzer\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --analysis-dir analysis\u002F\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --analysis-dir analysis\u002F --compact\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py \u003Cfile.kicad_sch> --output analysis.json  # one-off, no cache\n```\nOutputs structured JSON (~60-220KB depending on board complexity) with:\n- **Components & BOM**: inventory with reference, value, footprint, lib_id, type classification, MPN, datasheet; deduplicated BOM with quantities\n- **Nets**: full connectivity map with pin-to-net mapping, wire counts, no-connects\n- **Detected subcircuits** (pattern-matched circuits — all emitted as `findings[]` entries with matching `Det.*` detectors; use `get_findings(data, Det.POWER_REGULATORS)` etc. to fetch):\n  - Power regulators — LDO\u002Fswitching\u002Finverting topology, Vout estimation via datasheet-verified Vref lookup (~60 families) with heuristic fallback and fixed-output suffix parsing, `vref_source` (`datasheet`\u002F`lookup`\u002F`heuristic`\u002F`fixed_suffix`) and `vout_net_mismatch` fields\n  - Voltage dividers, RC\u002FLC filters (cutoff frequency), feedback networks, crystal circuits (load cap analysis, IC pin-based detection)\n  - Op-amp circuits (configuration, gain, integrator\u002Fcompensator), transistor circuits (net-name-aware load classification: motor\u002Fheater\u002Ffan\u002Fsolenoid\u002Fvalve\u002Fpump\u002Frelay\u002Fspeaker\u002Fbuzzer\u002Flamp; FET level shifter topology)\n  - Bridge circuits (H-bridge, 3-phase, cross-sheet detection), protection devices (ESD\u002FTVS), current sense, decoupling analysis\n  - Domain-specific: RF chains, RF matching networks, BMS, Ethernet (BFS PHY-to-connector tracing), HDMI\u002FDVI interfaces, memory interfaces, key matrices (net-name and topology-based), isolation barriers, addressable LED chains (WS2812\u002FSK6812\u002FAPA102), battery chargers (TP4056\u002FMCP73831\u002FBQ2404x), motor drivers (A4988\u002FTMC2209\u002FDRV8301), ESD protection coverage audit, debug interfaces (SWD\u002FJTAG with MCU tracing), power path (load switches\u002Fideal diodes\u002FUSB PD controllers), ADC signal conditioning (external ADCs + voltage references with anti-aliasing cross-ref), reset\u002Fsupervisor circuits (voltage supervisors\u002Fwatchdogs\u002FRC reset networks), clock distribution (clock generators\u002FPLLs\u002Foscillator output tracing), display\u002Ftouch interfaces (SSD1306\u002FILI9341\u002FST7789\u002FFT6236\u002FGT911), sensor fusion (IMU\u002Fenvironmental\u002Fmagnetometer with interrupt validation and bus clustering), level shifters (IC-based + discrete BSS138 with supply domain mapping), audio circuits (amplifiers\u002Fcodecs with I2S\u002Fclass-D detection), LED driver ICs (PWM\u002Fmatrix\u002Fconstant-current), RTC circuits (battery backup\u002Fcrystal pairing), LED lighting audit (current limiting validation), thermocouple\u002FRTD interfaces (MAX31855\u002FMAX31865), power sequencing validation (power tree\u002Fenable chain\u002FPG daisy chain analysis)\n- **IC pinout analysis**: pin-level connectivity, IC function classification (3-tier: library prefix, part number keywords, description fallback)\n- **Power analysis**: PDN impedance (1kHz–1GHz with MLCC parasitics), power budget, power sequencing (EN\u002FPG chains), sleep current audit (resistive paths + regulator Iq with EN detection), voltage derating, inrush estimation\n- **Design analysis**: ERC warnings, power domains, bus detection (I2C\u002FSPI\u002FUART\u002FCAN\u002FRS-485 with COPI\u002FCIPO\u002FSDI\u002FSDO), differential pairs (suffix-pair matching for USB\u002FLVDS\u002FEthernet\u002FHDMI\u002FMIPI\u002FPCIe\u002FSATA\u002FCAN\u002FRS-485), cross-domain signals (voltage equivalence), BOM optimization, test coverage, assembly complexity, USB compliance\n- **Quality checks**: annotation completeness, label validation, PWR_FLAG audit, footprint filter validation, sourcing audit, property pattern audit, generic transistor symbol detection (flags Q_NPN_*\u002FQ_PNP_*\u002FQ_NMOS_*\u002FQ_PMOS_* symbols with datasheet availability check)\n- **Structural**: MCU alternate pin summary, ground domain classification, bus topology, wire geometry, spatial clustering, pin coverage, hierarchical label validation\n\nSupports modern `.kicad_sch` (KiCad 6+) and legacy `.sch` (KiCad 4\u002F5). Hierarchical designs parsed recursively.\n\n**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.\n\n### Supplementary Data for Legacy Designs\n\nWhen `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.\n\nFor detailed parsing instructions, data recovery workflows, and a priority matrix of supplementary sources (netlist, cache library, PCB cross-reference, PDF exports), read `references\u002Fsupplementary-data-sources.md`.\n\n**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:\n\n1. **Component count** — grep for `(symbol (lib_id` blocks, subtract power symbols. Must match analyzer count exactly.\n2. **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\u002Flabels 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\u002FERC.\n3. **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:\n   - For transistors (BJT\u002FMOSFET) 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.\n   - When an MPN is specified, verify the symbol's pin-to-pad assignment against the datasheet's pinout diagram for that specific package.\n   - 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.\n   - **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?).\n4. **Net trace** — trace power rails and critical signal nets end-to-end through wires\u002Flabels. Verify the analyzer's pin list is complete for each net.\n5. **Regulator Vout** — check the `vref_source` field. `\"datasheet\"` means the Vref came from a trusted datasheet extraction and `\"lookup\"` from the datasheet-verified part table (~60 families); `\"heuristic\"` means a common reference fitted to the rail name when one lands within 10 % (else the first giving 0.5–60 V), a guess that needs manual verification. The `vout_net_mismatch` field flags estimated Vout differing >15% from the output rail name voltage.\n6. **Hierarchical connectivity** — on multi-sheet designs, verify sub-sheet connections are reflected in the net data.\n\nSee `references\u002Fschematic-analysis.md` Step 2 for the full verification checklist. If the script fails or returns unexpected results, see `references\u002Fmanual-schematic-parsing.md` for the complete fallback methodology.\n\n### PCB Layout Analyzer\n```bash\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --analysis-dir analysis\u002F --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --analysis-dir analysis\u002F --proximity  # add crosstalk analysis\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py \u003Cfile.kicad_pcb> --output pcb.json --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json  # one-off; cross-ref + power-rail auto-detect\n```\nOutputs structured JSON (~50-300KB depending on board complexity) with:\n- **Core**: footprint inventory (pads, courtyards, net assignments, extended attrs, schematic cross-reference), track\u002Fvia statistics, zone summaries, board outline\u002Fdimensions, routing completeness (proven from copper connectivity only with `--full`; without it, every multi-pad net has some copper)\n- **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\n- **Via analysis**: type breakdown (through\u002Fblind\u002Fmicro), annular ring checks, via-in-pad detection, BGA\u002FQFN fanout patterns, current capacity, stitching via identification, tenting\n- **Signal integrity**: per-net trace length, layer transition tracking (ground return paths), trace proximity\u002Fcrosstalk (with `--proximity`)\n- **Power & thermal**: current capacity per net, power net routing summary, ground domain identification (AGND\u002FDGND), zone stitching via density, thermal pad detection and via counting\n- **Manufacturing**: placement analysis (courtyard overlaps, edge clearance), decoupling cap distances, DFM scoring (JLCPCB standard\u002Fadvanced tier), tombstoning risk (0201\u002F0402 thermal asymmetry), thermal pad via adequacy, silkscreen documentation audit\n\nAdd `--full` to include individual track\u002Fvia 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.\n\n**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.\n\n**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 `analyze_copper_presence` findings (CP-001..CP-003) and `copper_presence_summary` show which components have zone copper on the opposite layer — use these for capacitive touch pad isolation, antenna keep-out, and thermal analysis instead of inferring copper presence from zone outlines.\n\n**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\u002Flength) for all copper-sensitive components. See `references\u002Fpcb-layout-analysis.md` → Copper-Sensitive Components for the full checklist.\n\n**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\u002Fmanual-pcb-parsing.md` for the fallback methodology.\n\n### PCB Rich Format and Assembly Checks\n\nAll PCB analysis sections now produce findings with the rich format (detector, rule_id, category, severity, confidence, summary, recommendation, report_context). Additionally, 7 new assembly\u002FDFM checks run automatically:\n\n- **FD-001**: Fiducial marker presence (>= 3 per SMD side)\n- **TE-001**: Test point coverage across signal nets\n- **OR-001**: Passive component orientation consistency\n- **SK-001**: Silkscreen text overlapping exposed pads\n- **VP-001**: Via in an SMD pad — warning when the pad's mask opening exposes it or it is untented, info when tented (--full mode)\n- **BV-001**: Via clearance from board edges (--full mode)\n- **KO-001**: Keepout zone violations\n- **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).\n\n### Cross-Domain Analysis\n\nAfter running both schematic and PCB analyzers, run the cross-domain analyzer.\nPoint `--schematic` and `--pcb` at the current run's JSON files and pass\n`--analysis-dir analysis\u002F` so the result lands inside the same run folder\nand the manifest tracks it:\n\n```\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py \\\n    --schematic analysis\u002F\u003Crun_id>\u002Fschematic.json \\\n    --pcb analysis\u002F\u003Crun_id>\u002Fpcb.json \\\n    --analysis-dir analysis\u002F\n\n# One-off (bypasses the cache)\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py \\\n    --schematic schematic.json --pcb pcb.json --output cross_analysis.json\n```\n\nChecks: CC-001 connector current capacity, EG-001 ESD protection gaps, DA-001 decoupling adequacy, XV-001..004 schematic\u002FPCB sync (parts paired by schematic path; XV-003 footprint, XV-004 MPN). PCB JSON optional.\n\nMechanical cross-verify (PCB vs schematic geometry): `python3 \u003Cskill-path>\u002Fscripts\u002Fcross_verify.py --help`.\n\n### Connectivity Graph (--full mode)\n\nWhen `--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. **The top-level keys of `connectivity_graph` are net names themselves** — e.g., `cg['GND']`, `cg['Net-(D2-K)']`, `cg['+3V3']` — *not* a `per_net` wrapper. Each net entry shows island count, component-to-island mapping (`{component:pad: island_id}`), gap locations, and disconnected pad pairs.\n\n### Gerber & Drill Analyzer\n```bash\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py \u003Cgerber_directory\u002F> --analysis-dir analysis\u002F\n\n# One-off\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_gerbers.py \u003Cgerber_directory\u002F> --output gerber.json\n```\nOutputs: layer identification (X2 attributes), component\u002Fnet\u002Fpin mapping (KiCad 6+ TO attributes), aperture function classification, trace width distribution, board dimensions, drill classification (via\u002Fcomponent\u002Fmounting), layer completeness, copper-outside-outline check, pad type summary (SMD\u002FTHT ratio). Add `--full` for complete pin-to-net connectivity dump. ~10KB JSON.\n\nThe gerber analyzer produces a `findings` list with rich format findings: GR-001 missing layers, GR-002 copper outside the board outline, GR-003 drill problems, GR-004 paste aperture mismatches, GR-005 open board outlines.\n\nIf the script fails or returns unexpected results, see `references\u002Fmanual-gerber-parsing.md` for the complete fallback methodology for parsing raw Gerber\u002FExcellon files directly.\n\nAll scripts output JSON to stdout by default. Prefer `--analysis-dir analysis\u002F`\nto integrate output into the run-folder convention described in \"Analysis\nCache Convention\" below — every analyzer in a single session then co-locates\ninside the same `analysis\u002F\u003Crun_id>\u002F` folder and is tracked by the manifest.\nUse `--output file.json` only for one-off runs where you don't want the\nresult cached. Add `--compact` for single-line JSON.\n\n**Analyzer JSON is worth keeping** — these are expensive to regenerate (large\nschematics take time). `--analysis-dir` preserves every run and is the form\ndownstream tools (diff_analysis, what_if) expect. They're not worth\ncommitting to git, but don't delete them between analysis steps.\n\n### Harmonized Output Format\n\nAll analyzers produce a uniform output envelope:\n\n```json\n{\n    \"analyzer_type\": \"schematic|pcb|emc|cross_analysis|thermal|gerber|lifecycle|spice\",\n    \"schema_version\": \"1.4.0\",\n    \"summary\": {\n        \"total_findings\": 42,\n        \"by_severity\": {\"error\": 3, \"warning\": 15, \"info\": 24}\n    },\n    \"findings\": [\n        {\"rule_id\": \"...\", \"detector\": \"...\", \"severity\": \"...\", \"confidence\": \"...\", \"evidence_source\": \"...\", \"summary\": \"...\", ...}\n    ],\n    \"trust_summary\": {\n        \"total_findings\": 42,\n        \"trust_level\": \"high|mixed|low\",\n        \"by_confidence\": {\"deterministic\": 20, \"heuristic\": 18, \"datasheet_backed\": 4},\n        \"by_evidence_source\": {\"datasheet\": 4, \"topology\": 10, \"heuristic_rule\": 18, ...},\n        \"provenance_coverage_pct\": 96.5\n    }\n}\n```\n\nThe `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`.\n\nAll analyzers support `--text` (human-readable report), `--analysis-dir`\n(run-folder output, preferred) and `--output` (one JSON file). Pass only one\nJSON destination: given both, schematic and PCB write only the run folder,\nEMC writes both, and gerber, thermal and cross-analysis write only `--output`.\n\n### Stage and Audience Filtering\n\nAll analyzers support `--stage` and `--audience` flags:\n\n**Stages:** `schematic`, `layout`, `pre_fab`, `bring_up`\n**Audiences:** `designer` (default), `reviewer`, `manager`\n\n```bash\n# Show only layout-relevant findings for a reviewer\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_pcb.py board.kicad_pcb --stage layout --audience reviewer --text\n\n# Manager summary of schematic review readiness\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_schematic.py design.kicad_sch --audience manager --text\n\n# Pre-fab checklist for cross-domain analysis\npython3 \u003Cskill-path>\u002Fscripts\u002Fcross_analysis.py -s sch.json -p pcb.json --stage pre_fab --text\n```\n\nJSON 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\u002Freviewer\u002Fmanager views. `--text` output respects both flags.\n\n### Generated Files\n\nAnalysis outputs are stored in `analysis\u002F` with timestamped run folders managed by `analysis_cache.py`. The manifest (`analysis\u002Fmanifest.json`) tracks all runs.\n\n| File Type | Location | Regenerable? | Commit to git? |\n|-----------|----------|-------------|----------------|\n| Analyzer JSON | `analysis\u002F\u003Ctimestamp>\u002F*.json` | Yes (expensive) | Configured by `track_in_git` in `.kicad-happy.json` (default: no) |\n| Manifest | `analysis\u002Fmanifest.json` | Yes | Always (tracked by default) |\n| Design review report | User-chosen path | Yes | Optional |\n\nWhen 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.\n\nSee also the `bom` skill's cleanup section for datasheets, order CSVs, and backups.\n\n### Analysis Cache Configuration\n\nThe `analysis` section in `.kicad-happy.json` controls the shared analysis output directory:\n\n```json\n{\n  \"analysis\": {\n    \"output_dir\": \"analysis\",\n    \"retention\": 0,\n    \"auto_diff\": true,\n    \"track_in_git\": false,\n    \"diff_threshold\": \"major\"\n  }\n}\n```\n\n| Field | Default | Description |\n|-------|---------|-------------|\n| `output_dir` | `\"analysis\"` | Analysis directory; relative paths resolve against the working directory |\n| `retention` | `0` | Max unpinned runs to keep. `0` = keep all (default) |\n| `auto_diff` | `true` | Auto-include delta section in design reviews |\n| `track_in_git` | `false` | When false, JSONs gitignored but manifest tracked |\n| `diff_threshold` | `\"major\"` | Severity that triggers new timestamped folder: `all` (= `minor`), `minor`, `major`, `breaking` |\n\nAll fields are optional. Missing fields use defaults.\n\n### Output JSON Schema Quick Reference\n\n**Schematic analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ninputs, compat, assessments, diagnostics, kicad_version, file_version, title_block, statistics,\nbom, components, nets, subcircuits, ic_pin_analysis, transistor_pin_analysis,\ndesign_analysis, connectivity_issues, rail_voltages\n```\nOptional (present when non-empty): `hierarchy_warning` (sub-sheet run without its root), `net_classifications`, `pdn_impedance`, `sleep_current_audit`, `power_budget`, `power_sequencing`, `bom_optimization`, `test_coverage`, `assembly_complexity`, `usb_compliance`, `inrush_analysis`, `sheets` (multi-sheet only), `missing_info`, `bom_lock`, `project_settings`\n\nKey nested structures:\n- `statistics`: `{total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}`\n- `bom[]`: `{reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}`\n- `components[]`: `{reference, value, footprint, lib_id, lib_name, type, category, mpn, datasheet, dnp, in_bom, parsed_value, ...}`\n- `nets{net_name}`: `{pins[], wires, labels[], ...}` — each pin: `{component, pin_number, pin_name, pin_type, ...}` (NOT `ref` or `pin`)\n- `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.\n- **Detected subcircuits live in `findings[]`** — power regulators, voltage dividers, RC\u002FLC filters, feedback networks, opamp\u002Ftransistor\u002Fbridge\u002Fcrystal circuits, current sense, decoupling, protection, buzzer\u002Fspeaker, Ethernet\u002FHDMI\u002Fmemory interfaces, RF chains\u002Fmatching, 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.\n\n**PCB analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ninputs, compat, assessments, diagnostics, kicad_version, file_version, statistics, layers, setup,\nnets, net_name_to_id, board_outline, component_groups, footprints,\ntracks, vias, zones, keepout_zones, connectivity, net_lengths\n```\nOptional: `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`, `thermal_pad_scan`, `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).\n\nKey nested structures:\n- `net_lengths` is a **list** (not dict): `[{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...]` sorted by length descending\n- `power_net_routing` is a **list**: `[{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]`\n- `footprints[]`: `{reference, value, footprint, layer, pad_nets{}, sch_path, sheetname, sheetfile, connected_nets[], ...}`\n- `statistics`: `{footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}`\n\n**Gerber analyzer top-level keys:**\n```\nanalyzer_type, schema_version, summary, findings, trust_summary,\ndirectory, generator, layer_count, statistics, completeness, alignment,\ndrill_classification, pad_summary, board_dimensions, gerbers, drills\n```\n\n**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\u002F` 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.\n\n**Before starting the workflow below for a design review:** read `references\u002Freport-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.\n\n1. **Scan the project directory** for `.kicad_sch`, `.kicad_pcb`, `.kicad_pro`, gerber directories, and `.net`\u002F`.xml` netlist files.\n2. **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.\n3. **Run the core analyzers.** If the schematic exists, run `analyze_schematic.py`. If the PCB exists, run `analyze_pcb.py --full --schematic \u003Cschematic JSON>` after it (SW-003 needs the schematic for the pad loop). If gerbers exist, run `analyze_gerbers.py` in parallel.\n4. **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\u002FPCB sync).\n5. **Run EMC pre-compliance** — when both schematic and PCB analysis exist, run `python3 \u003Cemc-skill-path>\u002Fscripts\u002Fanalyze_emc.py --schematic sch.json --pcb pcb.json` (the script lives in the `emc` skill — not under this skill's `\u003Cskill-path>`). 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.\n6. **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: `python3 \u003Cspice-skill-path>\u002Fscripts\u002Fsimulate_subcircuits.py sch.json`. This validates filter frequencies, divider ratios, opamp gains, and more against actual simulation results. SPICE takes \u003C1 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, run `python3 \u003Cspice-skill-path>\u002Fscripts\u002Fextract_parasitics.py pcb.json --output parasitics.json` (needs the `--full` PCB JSON) and pass `--parasitics parasitics.json` — a path argument, not a bare flag — to add trace R and via L to low-pass RC-filter benches (other benches ignore it). 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\u002FC3\"`), `status` (`pass`\u002F`warn`\u002F`fail`\u002F`info`\u002F`skip`), `expected` (dict of metric values), `simulated` (dict of measured values), `delta` (dict of error percentages).\n7. **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.\n8. **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 \u002F no network \u002F no MPNs].\"\n9. **Read the `.kicad_pro`** project file directly (it's JSON) for design rules, net classes, and DRC\u002FERC settings.\n10. **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.\n11. **Verify each output** against the raw files and datasheets before using the data in your report.\n12. **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\u002Freport-generation.md` for the report template.\n13. **Disclose all review gaps explicitly** — if thermal, lifecycle, gerber, datasheet extraction, or prior-review delta were not performed, add a short \"Not performed \u002F limits\" section to the report instead of omitting them silently.\n\nThe 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.\n\n### Analysis Depth\n\nDefault 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:\n\n- **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.\n- **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\u002Fsection numbers when reporting verification results.\n- **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.\n- **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.\n\n### Datasheet Acquisition\n\nBefore the Deep Review pass, check availability: the extraction cache\n(`datasheets\u002Fextracted\u002F`) is the fast path; PDFs on disk\n(`datasheets\u002F`) are the fallback — read them directly. If parts have\nneither, offer to sync datasheets (digikey \u002F lcsc \u002F mouser \u002F\nelement14 skills) before reviewing without them. Extractions carry a\nquality flag — low-quality facts come back flagged, not hidden;\ndecide whether to trust them or re-read the PDF.\n\nDatasheets 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.\n\n**Automated sync (preferred):** Run datasheet sync scripts early in the workflow. They download datasheets for all components with MPNs into a shared `datasheets\u002F` 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.\n\n```bash\npython3 \u003Cdigikey-skill-path>\u002Fscripts\u002Fsync_datasheets_digikey.py \u003Cfile.kicad_sch>\npython3 \u003Clcsc-skill-path>\u002Fscripts\u002Fsync_datasheets_lcsc.py \u003Cfile.kicad_sch>\npython3 \u003Celement14-skill-path>\u002Fscripts\u002Fsync_datasheets_element14.py \u003Cfile.kicad_sch>\npython3 \u003Cmouser-skill-path>\u002Fscripts\u002Fsync_datasheets_mouser.py \u003Cfile.kicad_sch>\n```\n\nDigiKey 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).\n\n**Check for existing datasheets:** Before downloading, look for:\n- `\u003Cproject>\u002Fdatasheets\u002F` with `manifest.json` (from a previous sync)\n- `\u003Cproject>\u002Fdocs\u002F` or `\u003Cproject>\u002Fdocumentation\u002F`\n- PDF files in the project directory whose names contain MPNs\n- `Datasheet` property URLs embedded in the KiCad symbols\n\n**Fallback methods when automated sync isn't available or misses parts:**\n1. Use the `Datasheet` property URL from the schematic symbol — many KiCad libraries include direct PDF links\n2. Use the `digikey` skill to search by MPN and download individual datasheets\n3. Use web search to find the manufacturer's datasheet page\n4. **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.\"\n\n**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.\n\n```bash\npython3 -c \"import sys; sys.path.insert(0, '\u003Cdatasheets-skill-path>\u002Fscripts'); from datasheet_page_selector import suggest_pages; s = suggest_pages('\u003Cpdf_path>', '\u003Cmpn>', '\u003Ccategory>'); print(s.pages, s.reasons)\"\n```\n\nAfter 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\u002Fextracted\u002F` (named by the cache manager, listed in `manifest.json`) and reused across reviews. The **`datasheets` skill** owns the full extraction pipeline (schema, page selection, scoring rubric, consumer API) — see `skills\u002Fdatasheets\u002FSKILL.md` and its reference guides.\n\n**What to extract from each datasheet** (note page\u002Fsection\u002Ffigure\u002Fequation numbers for citations):\n- Pin function table (pin number → name → function)\n- Absolute maximum ratings (voltage, current, temperature — including max continuous current through VCC\u002FGND pins, which constrains inrush)\n- Recommended application circuit and required external components\n- Required component values (and the equations that derive them)\n- Thermal characteristics\n\n**For passives:** While individual resistor\u002Fcapacitor 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.\n\n**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\u002Fcommunity 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\u002Fsection\u002Ffigure number in your report so the designer can confirm your work.\n\n### Schematic + PCB Cross-Reference\n\nWhen both files exist, cross-reference them. This catches the most expensive bugs — swapped pins, missing nets, and footprint mismatches pass DRC\u002FERC but produce non-functional boards.\n\n1. **Component count**: Schematic count (excluding power symbols) vs PCB footprint count.\n2. **Net consistency**: Verify schematic net names appear in PCB net declarations. Missing nets suggest incomplete routing or un-synced changes.\n3. **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:\n   - Custom\u002Fcommunity library symbols (may not match datasheet pinout)\n   - Multi-unit symbols (op-amps, gate arrays) — unit-to-pin assignment errors\n   - QFN\u002FBGA packages — pad numbering mistakes\n   - Transistors without MPNs — pinout ambiguity (see verification step 3)\n   - Polarized components — anode\u002Fcathode orientation\n   - Connectors — pin 1 orientation\n4. **Footprint match**: Schematic `Footprint` property vs actual PCB footprint (e.g., SOT-23 vs SOT-23-5).\n5. **DNP consistency**: DNP components in schematic should not have routing on PCB.\n6. **Value\u002FMPN consistency**: Values and MPNs match between schematic and PCB properties.\n\nThe PCB analyzer's `sch_path`, `sheetname`, and `sheetfile` fields in each footprint enable automated cross-referencing.\n\n### Diff-Aware Design Comparison\n\nCompare 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\u002Fdiff-analysis.md`.\n\n```bash\n# Compare two schematic analysis outputs (JSON to stdout)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json\n\n# Human-readable text output\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --text\n\n# Write to file, custom threshold (ignore \u003C2% deltas)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --output diff.json --threshold 2.0\n\n# Ignore small percentage changes (e.g., rounding noise)\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py base.json head.json --threshold 5.0 --text\n```\n\nAuto-detects analyzer type (schematic, PCB, EMC, SPICE). Reports:\n- **Components**: new, removed, value\u002Ffootprint\u002FMPN changes\n- **Signal analysis**: parameter shifts per detection type, driven by `detection_schema.SCHEMAS` identity and value fields\n- **BOM**: added\u002Fremoved line items, quantity changes\n- **Connectivity\u002FERC**: new\u002Fresolved single-pin nets, floating nets, multi-driver nets, ERC warnings\n- **EMC findings**: new\u002Fresolved findings with severity, risk score delta, per-net score changes\n- **SPICE results**: status transitions (pass->fail regressions, fail->pass fixes), Monte Carlo concern changes\n- **Severity classification**: `none` (no changes), `minor` (statistics only), `major` (component\u002Fsignal\u002Ffinding changes), `breaking` (SPICE regressions, new EMC `error` findings, new ERC warnings)\n\nAlso used programmatically by `analysis_cache.should_create_new_run()` to decide whether new outputs warrant a new timestamped run folder.\n\n### Thermal Hotspot Estimation\n\nEstimates 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\".\n\n```bash\n# Recommended: integrate into the current run\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py \\\n    -s analysis\u002F\u003Crun_id>\u002Fschematic.json \\\n    -p analysis\u002F\u003Crun_id>\u002Fpcb.json \\\n    --analysis-dir analysis\u002F\n\n# Human-readable text report\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py -s schematic.json -p pcb.json --text\n\n# Custom ambient temperature (default: 25°C), one-off output file\npython3 \u003Cskill-path>\u002Fscripts\u002Fanalyze_thermal.py -s schematic.json -p pcb.json --ambient 40 -o thermal.json\n```\n\nModels 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\u002FW, QFN-5x5: 25°C\u002FW, etc.) and is corrected for PCB thermal vias and copper pour. Rules:\n\n| Rule | Condition | Severity |\n|------|-----------|----------|\n| TS-001 | Tj exceeds absolute maximum | error |\n| TS-002 | Tj within 15°C of absolute maximum | error |\n| TS-003 | Tj > 85°C (may affect nearby passives) | warning |\n| TS-004 | P > 0.5W with no thermal vias | warning |\n| TS-005 | Significant power, within safe limits | info |\n| TP-001 | MLCC within 10mm of hot component | info |\n| TP-002 | Electrolytic cap within 10mm of hot component | warning |\n\nThermal 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).\n\n### Interactive \"What-If\" Parameter Sweep\n\nInstantly 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\u002Fwhat-if.md`](references\u002Fwhat-if.md).\n\n```bash\n# Single value change\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --text\n\n# Sweep: comma list or log range\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=1k,2.2k,4.7k,10k --text\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=1k..100k:10 --text\n\n# Tolerance corner analysis (±5% worst-case)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k+-5% C3=100n+-10% --text\n\n# Inverse solver, E-series snapping (divider target = Vout\u002FVin, e.g. 3.3 V of 5 V; filter = Hz)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json --fix 'voltage_dividers[0]' --target 0.66 --text\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json --fix 'rc_filters[0]' --target 1000 --text\n\n# EMC impact preview\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json C3=1u --emc --text\n\n# SPICE re-simulation on affected subcircuits\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --spice --text\n\n# Export patched JSON for further analysis (EMC, thermal, diff)\npython3 \u003Cskill-path>\u002Fscripts\u002Fwhat_if.py analysis.json R5=4.7k --output patched.json\n```\n\nPatches 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\u002Fafter 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.\n\n### Findings Summary\n\nSummarises 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\u002Fmanifest.json`.\n\n```bash\n# Top findings from the current run (default: top 20)\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F\n\n# Limit to the top 10 error findings\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --top 10 --severity error\n\n# JSON output for programmatic consumption\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --json\n\n# Summarise a specific run by ID\npython3 \u003Cskill-path>\u002Fscripts\u002Fsummarize_findings.py analysis\u002F --run \u003Crun_id>\n```\n\nFlags: `--top N` (default 20), `--severity` (filter to `error`\u002F`warning`\u002F`info`; `critical`\u002F`high` mean `error`), `--run` (explicit run ID instead of latest), `--json` (machine-readable output); also `--confidence`, `--evidence-source`, `--by-confidence`, `--only-deterministic`, `--no-deep-review` (see `--help`).\n\n### Component Lifecycle & Temperature Audit\n\nQueries 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.\n\n```bash\n# Basic lifecycle check\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json\n\n# With temperature range validation (preset or custom)\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --temp-range industrial\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --temp-range=\"-40,105\"\n\n# Query specific distributors only\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --only digikey,lcsc\n\n# Search for replacement parts when EOL\u002FNRND found\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --suggest-alternatives\n\n# Save results\npython3 \u003Cskill-path>\u002Fscripts\u002Flifecycle_audit.py analysis.json --output lifecycle.json\n```\n\nReads 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\u002F70°C), `industrial` (-40\u002F85°C), `extended` (-40\u002F105°C), `automotive` (-40\u002F125°C), `military` (-55\u002F125°C). Also checks datasheet extraction cache for temperature data before making API calls.\n\nThe lifecycle audit produces rich format findings: LC-001 (obsolete\u002Fdiscontinued), 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). When `--lifecycle` is NOT passed (the default), `analyze_schematic.py` emits an `LC-007` info finding noting that the audit was skipped — keeps the gap explicit in the report's findings list instead of being a silent omission.\n\n**Requires network access** — unlike the core analyzers, this script calls distributor APIs. Same environment variables as the distributor skills (DIGIKEY_CLIENT_ID\u002FSECRET, MOUSER_SEARCH_API_KEY, ELEMENT14_API_KEY). LCSC requires no credentials.\n\n### Schematic Analyzer Rule IDs\n\nAll schematic rule findings appear in `findings[]`. The following rule IDs are produced by the schematic analyzer:\n\n| Rule | Detector | Condition | Severity |\n|------|----------|-----------|----------|\n| SS-001 | `audit_sourcing_gate` | MPN coverage \u003C 50% | error |\n| SS-002 | `audit_sourcing_gate` | MPN coverage 50–80% | warning |\n| SS-003 | `audit_sourcing_gate` | MPN coverage 80–100% | info |\n| NT-001 | `analyze_connectivity` | Single-pin net: signal pin | warning |\n| NT-001 | `analyze_connectivity` | Single-pin net: power_out or passive pin | info |\n| RS-001 | `audit_rail_sources` | Rail has no declared source (no power_out pin, no PWR_FLAG, no bridged-jumper or regulator output) | warning |\n| RS-002 | `audit_rail_sources` | Rail depends on user closing an open jumper | error |\n| RS-003 | `audit_rail_sources` | Rail sourced indirectly via a bridged-by-default solder jumper or ferrite — functional but consider adding PWR_FLAG | info |\n| LB-001 | `detect_label_aliases` | Net has >= 2 distinct global\u002Fhierarchical labels (power nets excluded) | info |\n| PP-001 | `audit_power_pin_dc_paths` | IC power_in pin reaches a rail only through a capacitor (2-hop BFS) | error |\n| SP-001 | `detect_shorted_two_pin_components` | Two-pin passive or diode with both pins on one net (jumpers, net ties, 0R, DNP excluded); >= 5 on one net collapse into one net-level finding | warning |\n\nSS-001 is a pre-fab blocker — an `error` finding that should be resolved before ordering. NT-001 severity depends on pin type: signal pins (digital I\u002FO, bidirectional) are `warning`; power_out and passive pins are `info`. RS-001 is reserved for the \"no source at all\" case (warning); the softer \"sourced via bridged jumper \u002F ferrite\" case has its own rule_id RS-003 (info) so reviewers and CI gates can filter the two independently. 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. PP-001 demotes to `info` on module-internal LDO rails (`VDDPLL_*`, `VDDA_INT_*`, `VDDCORE_*`, `VCAP`, `VDDREG`) where decoupling-only is the correct topology.\n\n## Deep Review Pass\n\nAfter the analyzers have run, perform the Deep Review pass: a per-IC\ncomparison of actual usage against datasheet requirements. The\nanalyzers provide facts; this pass is where the judgment happens.\n\nFor each IC in the design:\n\n1. Pull its datasheet facts — extraction cache first\n   (`datasheets\u002Fextracted\u002F\u003Csanitized_mpn>.json`), PDF fallback (read it\n   directly). If neither exists, say \"\u003CREF> unverified — no datasheet\n   available\" in the review text, not in deep_review.json, and move on.\n2. Compare against actual usage in the analyzer JSON: supply voltages\n   vs ratings, pin functions vs connections, required externals\n   (inductors, caps, resistors) vs what the schematic has, thermal\n   context. Derive the checks from the datasheet — every part has\n   its own.\n3. Where a limit needs computing, write a disposable helper script\n   under `analysis\u002Fhelpers\u002F` that reads the analyzer JSON and prints\n   the numbers. Cite script + result as evidence.\n4. Record findings in `analysis\u002Fdeep_review.json` (shape:\n   `\u003Cskill-path>\u002Freview\u002Fschemas\u002Fdeep_review.schema.json`). Every\n   finding needs an evidence block: at least one design anchor\n   (component\u002Fnet\u002Fpin) and at least one source (datasheet quote\n   and\u002For computation).\n\nThen check interacting pairs: shared rails (sequencing, combined load), bus partners (voltage levels, pull-up ownership), thermal neighbors. Freestyle digging is encouraged — follow what looks wrong.\n\nValidate before reporting:\n\n```bash\npython3 \u003Cskill-path>\u002Freview\u002Fscripts\u002Fdeep_review_gate.py \\\n    analysis\u002Fdeep_review.json --analysis-dir analysis\u002F\n```\n\nThe gate verifies citations, stamps finding_ids, and moves failures\nto `quarantined[]` with reasons. Fix or accept quarantined entries;\nthe report renders them as unverified claims.\n\nRe-review: if `analysis\u002Fdeep_review.json` already exists from a prior\nreview, copy it aside first and open the new pass with a diff —\nreport fixed \u002F still-open \u002F new in the Previous Review Delta section:\n\n```bash\ncp analysis\u002Fdeep_review.json analysis\u002Fdeep_review.prev.json\n# ... run the pass, then the gate ...\npython3 \u003Cskill-path>\u002Fscripts\u002Fdiff_analysis.py \\\n    analysis\u002Fdeep_review.prev.json analysis\u002Fdeep_review.json --text\n```\n\nBig BOM: chunk by subsystem, or fan out per IC-group with subagents. See `references\u002Fdeep-review.md` for comparison heuristics per part class, pair-check patterns, and helper-script conventions. `analysis\u002Fdesign_context.json` (if present) steers priorities — e.g. automotive tightens derating attention. Optional; never block on it.\n\n## Reference Files\n\nDetailed methodology and format documentation lives in reference files. Read these as needed — they provide deep-dive content beyond what the scripts output automatically.\n\n| Reference | Lines | When to Read |\n|-----------|-------|-------------|\n| `deep-review.md` | 192 | Deep Review pass: per-part-class comparison heuristics, pair checks, helper-script conventions, fan-out |\n| `schematic-analysis.md` | 1167 | Deep schematic review: datasheet validation, design patterns, error taxonomy, tolerance stacking, GPIO audit, motor control, battery life, supply chain |\n| `pcb-layout-analysis.md` | 447 | Advanced PCB: impedance calculations, differential pairs, return paths, copper balance, edge clearance, copper-sensitive components (capacitive touch, antennas), custom analysis scripts |\n| `output-schema.md` | 347 | Full analyzer JSON schema with field names, types, and common extraction patterns |\n| `file-formats.md` | 382 | Manual file inspection: S-expression structure, field-by-field docs for all KiCad file types, version detection |\n| `gerber-parsing.md` | 761 | Gerber\u002FExcellon format details, X2 attributes, analysis techniques |\n| `pdf-schematic-extraction.md` | 315 | PDF schematic analysis: extraction workflow, notation conventions, KiCad translation |\n| `supplementary-data-sources.md` | 288 | Legacy KiCad 5 data recovery: netlist parsing, cache library, PCB cross-reference |\n| `net-tracing.md` | 181 | Manual net tracing: coordinate math, Y-axis inversion, rotation transforms |\n| `manual-schematic-parsing.md` | 291 | Fallback when schematic script fails |\n| `manual-pcb-parsing.md` | 459 | Fallback when PCB script fails |\n| `manual-gerber-parsing.md` | 648 | Fallback when Gerber script fails |\n| `report-generation.md` | 700 | Report template (critical findings at top), analyzer output field reference (schematic\u002FPCB\u002Fgerber), severity definitions, writing principles, domain-specific focus areas, known analyzer limitations |\n| `standards-compliance.md` | 638 | IPC\u002FIEC standards tables: conductor spacing (IPC-2221A Table 6-1), current capacity (IPC-2221A\u002FIPC-2152), annular rings, hole sizes, impedance, via protection (IPC-4761), creepage\u002Fclearance (ECMA-287\u002FIEC 60664-1). Consider for all boards; auto-trigger for professional\u002Findustrial designs, high voltage, mains input, or safety isolation. |\n| `oshwa-certification.md` | 89 | OSHWA open-source hardware certification readiness: editable KiCad sources, public documentation, licensing, version registration, certification-mark use. Read when the user asks about OSHWA certification or an open-source hardware release — a documentation\u002Flicensing audit with explicit approval gates, not an electrical check |\n| `design-intent.md` | 123 | Design intent resolution, target market \u002F certification \u002F power constraints that gate findings by context |\n| `diff-analysis.md` | 364 | How `diff_analysis.py` compares two analyzer runs and emits severity-ranked change reports |\n| `what-if.md` | 517 | How `what_if.py` patches component values, recalculates derived fields, and suggests fixes for feedback dividers \u002F crystal load caps \u002F cap derating |\n| `config-reference.md` | 405 | `.kicad-happy.json` schema — project config for analysis cache, suppressions, design intent, risk scoring |\n| `datasheet-verification.md` | 319 | Automated cross-check of schematic connections against structured datasheet extractions (pin voltage, required externals, decoupling adequacy) |\n\nFor script internals, data structures, signal analysis patterns, and batch test suite documentation, see `scripts\u002FREADME.md`.\n\n## File Types Quick Reference\n\n| Extension | Format | Purpose |\n|---|---|---|\n| `.kicad_pro` | JSON | Project settings, net classes, DRC\u002FERC severity, BOM fields |\n| `.kicad_sch` | S-expr | Schematic sheet (symbols, wires, labels, hierarchy) |\n| `.kicad_pcb` | S-expr | PCB layout (footprints, tracks, vias, zones, board outline) |\n| `.kicad_sym` | S-expr | Symbol library (schematic symbols with pins, graphics) |\n| `.kicad_mod` | S-expr | Single footprint (in `.pretty\u002F` directory) |\n| `.kicad_dru` | Custom | Custom design rules (DRC constraints) |\n| `fp-lib-table` \u002F `sym-lib-table` | S-expr | Library path tables |\n| `.sch` \u002F `.lib` \u002F `.dcm` | Legacy | KiCad 5 schematic, symbol library, descriptions |\n| `.net` \u002F `.xml` | S-expr\u002FXML | Netlist export, BOM export |\n| `.gbr` \u002F `.g*` \u002F `.drl` | Gerber\u002FExcellon | Manufacturing files (copper, mask, silk, outline, drill) |\n\nFor version detection and detailed field-by-field format documentation, read `references\u002Ffile-formats.md`. On Flatpak KiCad installs `kicad-cli` (native DRC\u002FERC reports, file exports) is not on PATH — invoke it as `flatpak run --command=kicad-cli org.kicad.KiCad \u003Cargs>`; its sandbox can't read host `\u002Ftmp`, so write exports\u002Fnetlists under the project directory (or elsewhere under `$HOME`) instead.\n\n## Analysis Strategies\n\n### Deep Schematic Analysis\n\nFor 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\u002Fschematic-analysis.md`. Use this reference whenever the user asks to review, validate, or analyze a schematic in depth.\n\n**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.\n\n### Deep PCB Analysis\n\nFor 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\u002Fpcb-layout-analysis.md`.\n\nMost 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.\n\n### Design Intent\n\nFor 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\u002Fdesign-intent.md`. Check the `design_intent` object in analysis output to understand the design context.\n\n### Probing Analyzer JSON\n\nDuring 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:\n\n**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.\n\n- Bad: `[Bash] python3 -c \"import json; d = json.load(open('analysis\u002F...\u002Fschematic.json')); print([...])\"` with no surrounding prose.\n- Good: \"Checking whether U3's EN pin is tied to +BATT directly or through a divider.\" then the probe.\n- Good: \"Verifying the detected TPS61023 topology matches the datasheet (buck-boost expected).\" then the probe.\n\nThe narrative matters most for probes that investigate *why* something looks wrong — those are the moments a user loses context fastest.\n\n**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.\n\n- 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.\n- Before `min()` \u002F `max()`, check non-empty: `min([])` raises `ValueError: min() iterable argument is empty`. Use `min(items, default=None)` or guard with `if items:`.\n- Use `.get(\"key\", default)` not `[\"key\"]` when a section may be absent (many sections are optional based on what the analyzer found).\n- `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.\n- 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\", \"\")`.\n- Pads\u002Fcomponents with missing data: `pad.get(\"abs_x\")` can be `None`; guard before arithmetic.\n\nSmall investment, much lower friction.\n\nFor probing the raw `.kicad_sch` \u002F `.kicad_pcb` files themselves (not the analyzer JSON), use `\u003Cskill-path>\u002Fscripts\u002Fkicad_core\u002Fsexp.py`: `parse(text)` and `parse_file(path)` return the document as nested Python lists; `find_all(node, kw)`, `find_first(node, kw)`, and `get_value(node, kw)` navigate it.\n\n### Quick Review Checklists\n\n**Schematic** — verify: decoupling caps on every IC VCC\u002FGND 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\u002FPG), adequate bulk capacitance.\n\n**PCB** — verify: power trace widths for current (IPC-2221), via current capacity, creepage\u002Fclearance for high voltage, decoupling cap proximity to IC power pins, continuous ground plane (no splits under signals), controlled impedance traces (USB\u002FDDR), 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\u002FDFN 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\u002Ftransistors\u002Fconnectors (catches library footprint pin numbering errors that are invisible to DRC\u002FERC — the most dangerous class of PCB bug). Consider `references\u002Fstandards-compliance.md` for IPC\u002FIEC standard values — conductor spacing and current capacity are relevant for most boards; creepage\u002Fclearance and via protection apply to mains-connected or safety-isolated designs.\n\n**Common bugs (ranked by board-killing potential)**: swapped IC pins (library symbol vs datasheet pinout — invisible to DRC\u002FERC), 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).\n\n### Report Generation\n\nWhen producing a design review report, read `references\u002Freport-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\u002Fpower\u002Fdesign 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.\n\n### Design Comparison\nWhen comparing two designs, diff: component counts\u002Ftypes, net classes\u002Fdesign rules, track widths\u002Fvia sizes, board dimensions\u002Flayer count, power supply topology, KiCad version differences.\n\n## Security Architecture\n\nAll analysis scripts process untrusted input (user-provided KiCad files,\nthird-party PDF datasheets, distributor API responses). The parsing architecture\nmitigates prompt injection and code execution risks:\n\n- **Deterministic parsers**: S-expression files (`.kicad_sch`, `.kicad_pcb`) are\n  parsed by a dedicated recursive-descent parser (`kicad_core\u002Fsexp.py`) — not\n  `eval()`, `exec()`, or any code execution primitive. The parser produces\n  Python lists\u002Fstrings only.\n- **Structured JSON boundary**: All analyzer output is structured JSON with a\n  fixed schema. External content (component values, net names, datasheet text)\n  is treated as data fields, never as instructions or code.\n- **PDF processing**: Datasheet PDFs are processed by `pdftotext` (external\n  binary, list-based args — no shell injection) and page content is passed to\n  the LLM for structured extraction. Extracted data is validated against a\n  5-dimension quality rubric before caching.\n- **No shell commands from input**: No analyzer constructs shell commands from\n  file content. Subprocess calls use list-based arguments exclusively.\n- **Read-only analysis**: Analysis scripts never modify input files. The BOM\n  write-back scripts do write when run; `--dry-run` previews the change.\n- **Distributor API scope**: Network requests are limited to known distributor\n  APIs (DigiKey, Mouser, LCSC, element14) for datasheet downloads and component\n  lookups. Only MPNs are sent — no design data leaves the local machine.\n",{"name":5,"description":7},"main","47790c5af225ba335e83c027413077333397539e","plugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad",490,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 02:12:02",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill kicad",{"tool":72,"command":73},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill kicad",{"tool":75,"command":76},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill kicad","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002FSKILL.md",true,[80,86,90,94,98,102,106,110,114,118,122,126,130,134,138,142,146,150,154,158,162,166,170,174,178,182,186,190,194,200,204,208,212,216,220,224,228,232,236,240,244,248,252,256,260,264,268,272,276,280,284,288,292,296,300,304,308,312,316,320,324,328,332,335,339,343,347,351,355,359,363,367,371,375,379,383,387,391,395,399,403,407,411,415,419,423,427,431,435,439,443,447,451,455,459,463,467,470,474,478,482,486,490,494,498,502,506,510,514,518,522,526,529,533,537,541,545,549,553,557,561,565,569,573,577,581,585,589],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fconfig-reference.md","REFERENCE","参考文档",18785,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fconfig-reference.md",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fdatasheet-verification.md",16904,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fdatasheet-verification.md",{"path":91,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fdeep-review.md",9611,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fdeep-review.md",{"path":95,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fdesign-intent.md",5591,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fdesign-intent.md",{"path":99,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fdiff-analysis.md",17827,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fdiff-analysis.md",{"path":103,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Ffile-formats.md",14693,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Ffile-formats.md",{"path":107,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fgerber-parsing.md",33984,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fgerber-parsing.md",{"path":111,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fmanual-gerber-parsing.md",25006,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fmanual-gerber-parsing.md",{"path":115,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fmanual-pcb-parsing.md",17655,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fmanual-pcb-parsing.md",{"path":119,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fmanual-schematic-parsing.md",13074,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fmanual-schematic-parsing.md",{"path":123,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fnet-tracing.md",12237,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fnet-tracing.md",{"path":127,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Foshwa-certification.md",4622,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Foshwa-certification.md",{"path":131,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":132,"sourceHtmlUrl":133},"references\u002Foutput-schema.md",34198,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Foutput-schema.md",{"path":135,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":136,"sourceHtmlUrl":137},"references\u002Fpcb-layout-analysis.md",27987,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fpcb-layout-analysis.md",{"path":139,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":140,"sourceHtmlUrl":141},"references\u002Fpdf-schematic-extraction.md",15537,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fpdf-schematic-extraction.md",{"path":143,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":144,"sourceHtmlUrl":145},"references\u002Freport-generation.md",57371,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Freport-generation.md",{"path":147,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":148,"sourceHtmlUrl":149},"references\u002Fschematic-analysis.md",65471,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fschematic-analysis.md",{"path":151,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":152,"sourceHtmlUrl":153},"references\u002Fstandards-compliance.md",34316,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fstandards-compliance.md",{"path":155,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":156,"sourceHtmlUrl":157},"references\u002Fsupplementary-data-sources.md",12756,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fsupplementary-data-sources.md",{"path":159,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":160,"sourceHtmlUrl":161},"references\u002Fwhat-if.md",19938,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freferences\u002Fwhat-if.md",{"path":163,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":164,"sourceHtmlUrl":165},"review\u002Ffixtures\u002Fdeep_review.example.json",1265,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Ffixtures\u002Fdeep_review.example.json",{"path":167,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":168,"sourceHtmlUrl":169},"review\u002Ffixtures\u002Fdesign_context.example.json",388,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Ffixtures\u002Fdesign_context.example.json",{"path":171,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":172,"sourceHtmlUrl":173},"review\u002Ffixtures\u002Freview_annotations.example.json",707,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Ffixtures\u002Freview_annotations.example.json",{"path":175,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":176,"sourceHtmlUrl":177},"review\u002Fprompts\u002Fdesign_context.md",5022,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fprompts\u002Fdesign_context.md",{"path":179,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":180,"sourceHtmlUrl":181},"review\u002FREADME.md",4249,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002FREADME.md",{"path":183,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":184,"sourceHtmlUrl":185},"review\u002Fschemas\u002Fdeep_review.schema.json",3345,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fschemas\u002Fdeep_review.schema.json",{"path":187,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":188,"sourceHtmlUrl":189},"review\u002Fschemas\u002Fdesign_context.schema.json",2293,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fschemas\u002Fdesign_context.schema.json",{"path":191,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":192,"sourceHtmlUrl":193},"review\u002Fschemas\u002Freview_annotations.schema.json",1971,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fschemas\u002Freview_annotations.schema.json",{"path":195,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":198,"sourceHtmlUrl":199},"review\u002Fscripts\u002F_mini_jsonschema.py","SCRIPT","脚本",6738,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002F_mini_jsonschema.py",{"path":201,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":202,"sourceHtmlUrl":203},"review\u002Fscripts\u002Fbuild_review_plan.py",2342,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002Fbuild_review_plan.py",{"path":205,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":206,"sourceHtmlUrl":207},"review\u002Fscripts\u002Fdeep_review_gate.py",23753,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002Fdeep_review_gate.py",{"path":209,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":210,"sourceHtmlUrl":211},"review\u002Fscripts\u002Fmerge_annotations.py",7020,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002Fmerge_annotations.py",{"path":213,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":214,"sourceHtmlUrl":215},"review\u002Fscripts\u002Frun_phase4_exercise.py",12540,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002Frun_phase4_exercise.py",{"path":217,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":218,"sourceHtmlUrl":219},"review\u002Fscripts\u002Fvalidate_review.py",2593,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Freview\u002Fscripts\u002Fvalidate_review.py",{"path":221,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":222,"sourceHtmlUrl":223},"scripts\u002F.gitignore",13,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002F.gitignore",{"path":225,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":226,"sourceHtmlUrl":227},"scripts\u002Fanalysis_cache.py",34103,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalysis_cache.py",{"path":229,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":230,"sourceHtmlUrl":231},"scripts\u002Fanalyze_gerbers.py",89177,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalyze_gerbers.py",{"path":233,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":234,"sourceHtmlUrl":235},"scripts\u002Fanalyze_pcb.py",7338,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalyze_pcb.py",{"path":237,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":238,"sourceHtmlUrl":239},"scripts\u002Fanalyze_schematic.py",6801,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalyze_schematic.py",{"path":241,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":242,"sourceHtmlUrl":243},"scripts\u002Fanalyze_thermal.py",48754,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalyze_thermal.py",{"path":245,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":246,"sourceHtmlUrl":247},"scripts\u002Fanalyzer_envelope.py",15848,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fanalyzer_envelope.py",{"path":249,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":250,"sourceHtmlUrl":251},"scripts\u002Fcapability_mode.py",9499,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fcapability_mode.py",{"path":253,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":254,"sourceHtmlUrl":255},"scripts\u002Fcheck_report_sections.py",9741,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fcheck_report_sections.py",{"path":257,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":258,"sourceHtmlUrl":259},"scripts\u002Fcross_analysis.py",65894,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fcross_analysis.py",{"path":261,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":262,"sourceHtmlUrl":263},"scripts\u002Fcross_verify.py",23636,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fcross_verify.py",{"path":265,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":266,"sourceHtmlUrl":267},"scripts\u002Fdesign_intent.py",13567,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdesign_intent.py",{"path":269,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":270,"sourceHtmlUrl":271},"scripts\u002Fdetection_schema.py",26593,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdetection_schema.py",{"path":273,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":274,"sourceHtmlUrl":275},"scripts\u002Fdetector_helpers.py",15444,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdetector_helpers.py",{"path":277,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":278,"sourceHtmlUrl":279},"scripts\u002Fdiff_analysis.py",22958,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdiff_analysis.py",{"path":281,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":282,"sourceHtmlUrl":283},"scripts\u002Fdiff_engine.py",48291,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdiff_engine.py",{"path":285,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":286,"sourceHtmlUrl":287},"scripts\u002Fdomain_detectors.py",263513,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fdomain_detectors.py",{"path":289,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":290,"sourceHtmlUrl":291},"scripts\u002Fenvelopes\u002F__init__.py",0,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002F__init__.py",{"path":293,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":294,"sourceHtmlUrl":295},"scripts\u002Fenvelopes\u002Fcross_analysis.py",6028,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002Fcross_analysis.py",{"path":297,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":298,"sourceHtmlUrl":299},"scripts\u002Fenvelopes\u002Fgerber.py",16452,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002Fgerber.py",{"path":301,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":302,"sourceHtmlUrl":303},"scripts\u002Fenvelopes\u002Fpcb.py",26341,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002Fpcb.py",{"path":305,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":306,"sourceHtmlUrl":307},"scripts\u002Fenvelopes\u002Fschematic.py",23647,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002Fschematic.py",{"path":309,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":310,"sourceHtmlUrl":311},"scripts\u002Fenvelopes\u002Fthermal.py",7537,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fenvelopes\u002Fthermal.py",{"path":313,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":314,"sourceHtmlUrl":315},"scripts\u002Fexport_issues.py",26536,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fexport_issues.py",{"path":317,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":318,"sourceHtmlUrl":319},"scripts\u002Ffab_release_gate.py",29224,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Ffab_release_gate.py",{"path":321,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":322,"sourceHtmlUrl":323},"scripts\u002Ffinding_schema.py",26290,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Ffinding_schema.py",{"path":325,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":326,"sourceHtmlUrl":327},"scripts\u002Fgen_output_schema_md.py",9467,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fgen_output_schema_md.py",{"path":329,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":330,"sourceHtmlUrl":331},"scripts\u002Finputs_builder.py",4072,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Finputs_builder.py",{"path":333,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":290,"sourceHtmlUrl":334},"scripts\u002Fkicad_core\u002F__init__.py","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002F__init__.py",{"path":336,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":337,"sourceHtmlUrl":338},"scripts\u002Fkicad_core\u002Fclassify.py",31411,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fclassify.py",{"path":340,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":341,"sourceHtmlUrl":342},"scripts\u002Fkicad_core\u002Fcli.py",4097,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fcli.py",{"path":344,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":345,"sourceHtmlUrl":346},"scripts\u002Fkicad_core\u002Fcoords.py",2008,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fcoords.py",{"path":348,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":349,"sourceHtmlUrl":350},"scripts\u002Fkicad_core\u002Fdiagnostics.py",1904,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fdiagnostics.py",{"path":352,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":353,"sourceHtmlUrl":354},"scripts\u002Fkicad_core\u002Fexecutables.py",1026,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fexecutables.py",{"path":356,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":357,"sourceHtmlUrl":358},"scripts\u002Fkicad_core\u002Ffields.py",6042,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Ffields.py",{"path":360,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":361,"sourceHtmlUrl":362},"scripts\u002Fkicad_core\u002Ffileio.py",3575,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Ffileio.py",{"path":364,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":365,"sourceHtmlUrl":366},"scripts\u002Fkicad_core\u002Fhotloop.py",3167,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fhotloop.py",{"path":368,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":369,"sourceHtmlUrl":370},"scripts\u002Fkicad_core\u002Finstances.py",5842,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Finstances.py",{"path":372,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":373,"sourceHtmlUrl":374},"scripts\u002Fkicad_core\u002Fmodel.py",4558,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fmodel.py",{"path":376,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":377,"sourceHtmlUrl":378},"scripts\u002Fkicad_core\u002Fnetnames.py",14329,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fnetnames.py",{"path":380,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":381,"sourceHtmlUrl":382},"scripts\u002Fkicad_core\u002Fnetquery.py",6892,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fnetquery.py",{"path":384,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":385,"sourceHtmlUrl":386},"scripts\u002Fkicad_core\u002Fpairing.py",1897,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fpairing.py",{"path":388,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":389,"sourceHtmlUrl":390},"scripts\u002Fkicad_core\u002Fparts.py",24570,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fparts.py",{"path":392,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":393,"sourceHtmlUrl":394},"scripts\u002Fkicad_core\u002Fpassives.py",10163,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fpassives.py",{"path":396,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":397,"sourceHtmlUrl":398},"scripts\u002Fkicad_core\u002Fpdn.py",1011,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fpdn.py",{"path":400,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":401,"sourceHtmlUrl":402},"scripts\u002Fkicad_core\u002Fproject.py",34877,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fproject.py",{"path":404,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":405,"sourceHtmlUrl":406},"scripts\u002Fkicad_core\u002Frender.py",2714,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Frender.py",{"path":408,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":409,"sourceHtmlUrl":410},"scripts\u002Fkicad_core\u002Fsexp.py",11617,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fsexp.py",{"path":412,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":413,"sourceHtmlUrl":414},"scripts\u002Fkicad_core\u002Ftextvars.py",5580,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Ftextvars.py",{"path":416,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":417,"sourceHtmlUrl":418},"scripts\u002Fkicad_core\u002Ftoken_cache.py",2251,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Ftoken_cache.py",{"path":420,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":421,"sourceHtmlUrl":422},"scripts\u002Fkicad_core\u002Fvalues.py",13952,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_core\u002Fvalues.py",{"path":424,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":425,"sourceHtmlUrl":426},"scripts\u002Fkicad_types.py",13087,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fkicad_types.py",{"path":428,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":429,"sourceHtmlUrl":430},"scripts\u002Flifecycle_audit.py",6783,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Flifecycle_audit.py",{"path":432,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":433,"sourceHtmlUrl":434},"scripts\u002Flifecycle_engine.py",48521,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Flifecycle_engine.py",{"path":436,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":437,"sourceHtmlUrl":438},"scripts\u002Flookup_detectors.py",30441,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Flookup_detectors.py",{"path":440,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":441,"sourceHtmlUrl":442},"scripts\u002Flookup_helpers.py",2015,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Flookup_helpers.py",{"path":444,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":445,"sourceHtmlUrl":446},"scripts\u002Fmethodology_gerbers.md",23370,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fmethodology_gerbers.md",{"path":448,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":449,"sourceHtmlUrl":450},"scripts\u002Fmethodology_pcb.md",22609,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fmethodology_pcb.md",{"path":452,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":453,"sourceHtmlUrl":454},"scripts\u002Fmethodology_schematic.md",43021,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fmethodology_schematic.md",{"path":456,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":457,"sourceHtmlUrl":458},"scripts\u002Fnetlist_queries.py",4324,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fnetlist_queries.py",{"path":460,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":461,"sourceHtmlUrl":462},"scripts\u002Foutput_filters.py",17161,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Foutput_filters.py",{"path":464,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":465,"sourceHtmlUrl":466},"scripts\u002Foutput_io.py",5106,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Foutput_io.py",{"path":468,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":290,"sourceHtmlUrl":469},"scripts\u002Fpcb\u002F__init__.py","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002F__init__.py",{"path":471,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":472,"sourceHtmlUrl":473},"scripts\u002Fpcb\u002Fassembly.py",57153,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fassembly.py",{"path":475,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":476,"sourceHtmlUrl":477},"scripts\u002Fpcb\u002Fconnectivity.py",28399,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fconnectivity.py",{"path":479,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":480,"sourceHtmlUrl":481},"scripts\u002Fpcb\u002Fcopper.py",59675,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fcopper.py",{"path":483,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":484,"sourceHtmlUrl":485},"scripts\u002Fpcb\u002Fdfm.py",63292,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fdfm.py",{"path":487,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":488,"sourceHtmlUrl":489},"scripts\u002Fpcb\u002Fgeometry.py",58210,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fgeometry.py",{"path":491,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":492,"sourceHtmlUrl":493},"scripts\u002Fpcb\u002Fpipeline.py",28698,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fpipeline.py",{"path":495,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":496,"sourceHtmlUrl":497},"scripts\u002Fpcb\u002Fpresentation.py",22315,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Fpresentation.py",{"path":499,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":500,"sourceHtmlUrl":501},"scripts\u002Fpcb\u002Freader.py",86711,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Freader.py",{"path":503,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":504,"sourceHtmlUrl":505},"scripts\u002Fpcb\u002Frouting.py",54805,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fpcb\u002Frouting.py",{"path":507,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":508,"sourceHtmlUrl":509},"scripts\u002Fproject_config.py",22658,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fproject_config.py",{"path":511,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":512,"sourceHtmlUrl":513},"scripts\u002FREADME.md",23991,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002FREADME.md",{"path":515,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":516,"sourceHtmlUrl":517},"scripts\u002Frisk_summary.py",3181,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Frisk_summary.py",{"path":519,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":520,"sourceHtmlUrl":521},"scripts\u002Frun_id.py",1690,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Frun_id.py",{"path":523,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":524,"sourceHtmlUrl":525},"scripts\u002Fschema_codec.py",5171,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschema_codec.py",{"path":527,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":290,"sourceHtmlUrl":528},"scripts\u002Fschematic\u002F__init__.py","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002F__init__.py",{"path":530,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":531,"sourceHtmlUrl":532},"scripts\u002Fschematic\u002Faudits.py",56169,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Faudits.py",{"path":534,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":535,"sourceHtmlUrl":536},"scripts\u002Fschematic\u002Fbom_stats.py",6044,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fbom_stats.py",{"path":538,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":539,"sourceHtmlUrl":540},"scripts\u002Fschematic\u002Fconnectivity.py",60974,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fconnectivity.py",{"path":542,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":543,"sourceHtmlUrl":544},"scripts\u002Fschematic\u002Ferc_pins.py",8568,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Ferc_pins.py",{"path":546,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":547,"sourceHtmlUrl":548},"scripts\u002Fschematic\u002Fhierarchy.py",20460,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fhierarchy.py",{"path":550,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":551,"sourceHtmlUrl":552},"scripts\u002Fschematic\u002Fic_analysis.py",21894,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fic_analysis.py",{"path":554,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":555,"sourceHtmlUrl":556},"scripts\u002Fschematic\u002Flegacy_reader.py",50601,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Flegacy_reader.py",{"path":558,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":559,"sourceHtmlUrl":560},"scripts\u002Fschematic\u002Fnet_analysis.py",75500,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fnet_analysis.py",{"path":562,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":563,"sourceHtmlUrl":564},"scripts\u002Fschematic\u002Fpipeline.py",71288,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fpipeline.py",{"path":566,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":567,"sourceHtmlUrl":568},"scripts\u002Fschematic\u002Fpresentation.py",21278,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fpresentation.py",{"path":570,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":571,"sourceHtmlUrl":572},"scripts\u002Fschematic\u002Freader.py",63850,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Freader.py",{"path":574,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":575,"sourceHtmlUrl":576},"scripts\u002Fschematic\u002Fsystem_analyses.py",127665,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fschematic\u002Fsystem_analyses.py",{"path":578,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":579,"sourceHtmlUrl":580},"scripts\u002Fsignal_detectors.py",240365,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fsignal_detectors.py",{"path":582,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":583,"sourceHtmlUrl":584},"scripts\u002Fsummarize_findings.py",17784,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fsummarize_findings.py",{"path":586,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":587,"sourceHtmlUrl":588},"scripts\u002Fvalidation_detectors.py",73013,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fvalidation_detectors.py",{"path":590,"resourceType":196,"resourceTypeDesc":197,"sizeBytes":591,"sourceHtmlUrl":592},"scripts\u002Fwhat_if.py",69509,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Faklofas\u002Fkicad-happy\u002Fskills\u002Fkicad\u002Fscripts\u002Fwhat_if.py",[594,602,609,616,641,666],{"skillNo":595,"name":596,"nameZh":6,"description":597,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":598,"categories":599,"keywords":600,"publishedAt":601},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":603,"name":604,"nameZh":6,"description":605,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":606,"categories":607,"keywords":608,"publishedAt":601},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":610,"name":611,"nameZh":6,"description":612,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":613,"categories":614,"keywords":615,"publishedAt":601},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":617,"name":618,"nameZh":6,"description":619,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":620,"categories":621,"keywords":622,"publishedAt":51},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[623,624,625,626,42,627,628,629,630,50,631,632,633,634,635,636,637,638,639,640],"search","deja search","never","error","memory","re","decide","fix","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":642,"name":643,"nameZh":6,"description":644,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":645,"categories":646,"keywords":647,"publishedAt":51},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[648,649,650,636,651,652,653,654,655,656,657,658,659,660,627,661,662,663,664,665],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":667,"name":668,"nameZh":6,"description":669,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":670,"categories":671,"keywords":681,"publishedAt":51},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[672,675,678],{"categoryNo":673,"categoryName":674,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":676,"categoryName":677,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":679,"categoryName":680,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[668,682,683,684,685,41,686,662,687,628,688,689,690,691,632,692,693,694,695,696],"URL","Video","short-form","standalone","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]