From kicad-happy
Orchestrates BOM management for KiCad electronics projects: analyzes schematics, searches distributors (DigiKey, Mouser, LCSC, element14), updates symbol properties, exports CSVs and order files.
npx claudepluginhub aklofas/kicad-happy --plugin kicad-happyThis skill uses the workspace's default tool permissions.
BOM data lives in **KiCad schematic symbol properties** as the single source of truth. This skill orchestrates the full lifecycle: analyze the schematic, search distributors, validate parts, write properties back, export tracking CSVs, and generate order files.
Supports JLCPCB PCB fabrication and assembly: BOM/CPL generation, basic vs extended parts, assembly constraints, design rules, ordering workflow. For KiCad users ordering prototypes or assembled boards.
Searches registries and web for electronic components and reusable subcircuits to add to Zener PCB projects. Use during board, module, or subsystem design with pcb search and pcb new component.
Conducts multi-round deep research on GitHub repos via API and web searches, generating markdown reports with executive summaries, timelines, metrics, and Mermaid diagrams.
Share bugs, ideas, or general feedback.
BOM data lives in KiCad schematic symbol properties as the single source of truth. This skill orchestrates the full lifecycle: analyze the schematic, search distributors, validate parts, write properties back, export tracking CSVs, and generate order files.
| Skill | Purpose |
|---|---|
kicad | Read/analyze schematics, PCB, footprints |
digikey | Search DigiKey, download datasheets (primary prototype source) |
mouser | Search Mouser (secondary prototype source) |
lcsc | Search LCSC (production/JLCPCB parts) |
element14 | Search Newark/Farnell/element14 (international) |
jlcpcb | PCB fabrication & assembly ordering |
pcbway | Alternative PCB fab & assembly |
Use <skill-path> to reference the BOM skill directory.
# Analyze schematic (JSON output, recursive sub-sheets)
python3 <skill-path>/scripts/bom_manager.py analyze path/to/schematic.kicad_sch --json --recursive
# Export BOM tracking CSV (creates new or merges with existing)
python3 <skill-path>/scripts/bom_manager.py export path/to/schematic.kicad_sch -o bom/bom.csv --recursive
# Generate per-distributor order files (5 boards + 2 spares/line)
python3 <skill-path>/scripts/bom_manager.py order bom/bom.csv --boards 5 --spares 2
# Quick single-distributor order (bypasses Chosen_Distributor column)
python3 <skill-path>/scripts/bom_manager.py order bom/bom.csv --distributor digikey
# Write properties to schematic (dry-run first, then apply)
echo '{"R1": {"MPN": "RC0805FR-0710KL", "Manufacturer": "Yageo"}}' \
| python3 <skill-path>/scripts/edit_properties.py path/to/schematic.kicad_sch --dry-run
# Sync datasheet URLs from manifest.json back into schematic Datasheet properties
python3 <skill-path>/scripts/sync_datasheet_urls.py path/to/schematic.kicad_sch --recursive --dry-run
Skip steps that don't apply. Common shortcuts:
--gaps-only, address each missing fieldsync_datasheet_urls.py to backfill empty Datasheet fields from the datasheets manifestpython3 <skill-path>/scripts/bom_manager.py analyze path/to/schematic.kicad_sch --json --recursive
The output tells you the project's field naming convention, which distributors are populated, what's missing, and the preferred distributor. Also look for an existing BOM tracking CSV in the project directory or bom/ folder.
The script covers common patterns, but some projects use internal key systems or parametric fields. See references/part-number-conventions.md for the full catalog. Read the schematic if something seems off.
Do this immediately. Datasheets are essential context for validation and part selection. Run the preferred distributor's sync first; if some fail, try others — they share the same datasheets/ directory and skip already-downloaded parts.
python3 <digikey-skill-path>/scripts/sync_datasheets_digikey.py path/to/schematic.kicad_sch --recursive
python3 <lcsc-skill-path>/scripts/sync_datasheets_lcsc.py path/to/schematic.kicad_sch --recursive
python3 <element14-skill-path>/scripts/sync_datasheets_element14.py path/to/schematic.kicad_sch --recursive
DigiKey is best (direct PDF URLs). element14 is reliable (no bot protection). LCSC works for LCSC-only parts. Mouser is a last resort (often blocks downloads).
Tell the user where datasheets are (e.g., hardware/<project>/datasheets/). They'll reference them often.
Cross-revision projects: Use a single shared datasheets directory at the project level rather than per-revision. The same MPN's datasheet doesn't change between revisions.
Re-sync after writing new MPNs (Step 5) — the scripts are idempotent. Then backfill Datasheet URLs into the schematic:
python3 <skill-path>/scripts/sync_datasheet_urls.py path/to/schematic.kicad_sch --recursive
This reads datasheets/manifest.json (legacy name index.json still supported) and writes discovered datasheet URLs into empty schematic Datasheet properties. Opportunistic — only fills blanks. If a schematic already has a different URL, it warns about the mismatch without overwriting (use --overwrite to replace). Run with --dry-run first to preview.
Watch for comma-separated MPNs. Some symbols track multiple physical parts (e.g., battery holder + clip). Split on commas and search each MPN independently — searching the combined string matches the wrong product.
Search strategy based on what's available:
Use the project's preferred distributor first, then alternates. Prototype: DigiKey primary, Mouser secondary. Production: LCSC.
Don't assume existing PNs are correct — distributor PNs go stale (discontinued, renumbered). Verify existing PNs resolve against the API. If a PN returns 404, flag it for replacement.
For every match, verify:
If ambiguous, ask the user. A wrong part is worse than a missing part.
KiCad coexistence. The script detects KiCad's lock file and warns but proceeds. KiCad doesn't auto-detect external changes — it keeps its in-memory copy. If KiCad is open, tell the user: "Close and reopen the schematic (File → Open Recent) to see the changes. Don't save from KiCad first."
If unsaved KiCad work exists, ask them to save first (Ctrl+S), then run the script, then reopen.
echo '{"R1": {"MPN": "RC0805FR-0710KL", "Manufacturer": "Yageo", "DigiKey": "311-10.0KCRCT-ND"}}' \
| python3 <skill-path>/scripts/edit_properties.py path/to/schematic.kicad_sch
Backups: By default, no .bak file is created (git tracks changes). Pass --backup if the schematic is not in a git repo or has uncommitted changes the user wants to preserve.
Respect the project's convention. Write to "Digi-Key_PN" if that's what exists, not "DigiKey". Use canonical names only for new projects.
Always write Manufacturer alongside MPN — every API returns it, it's free data.
python3 <skill-path>/scripts/bom_manager.py export path/to/schematic.kicad_sch -o bom/bom.csv --recursive
CSV columns are dynamic — only distributors the project uses get columns. Base columns: Reference, Qty, Value, Footprint, MPN, Manufacturer. Each active distributor gets a PN column + stock column. Tail columns: Chosen_Distributor, Datasheet, Validated, DNP, Notes.
The Notes column is seeded from schematic BOM Comments properties (or aliases like Notes, Remarks, Ordering Notes, etc.) on first export. On re-export, user edits in the CSV take priority — existing Notes values are preserved and schematic-sourced comments won't overwrite them.
Merge behavior: Re-exporting preserves user-managed columns (stock, Chosen_Distributor, Validated, Notes) while updating schematic-derived columns.
For each part with a distributor PN, query current stock via the corresponding distributor skill. Update stock columns in the CSV. Stock data goes stale — note the date and re-check before ordering.
If the chosen distributor is out of stock, flag it and suggest the alternate.
Factors: stock availability, price at order qty, minimum order/multiples, lead time, shipping consolidation (fewer distributors = fewer shipments).
For prototypes, consolidate to 1-2 distributors (DigiKey + Mouser). For production, LCSC/JLCPCB is cheapest.
Re-run Step 2 (download + URL backfill) to pick up parts added in Steps 3-5. Fast — already-downloaded files are skipped.
Read downloaded datasheets and verify parts are functionally correct for the circuit. This catches wrong-part-number errors that Step 4 might miss.
What to check by type:
For large BOMs (50+ parts), focus on power components, critical signal paths, and anything the user flagged. Commodity passives usually don't need deep review.
Ask how many boards if not already known — this sets the --boards multiplier.
Pre-flight: verify no gaps, CSV is current, Chosen_Distributor is set (or use --distributor flag), stock is fresh.
# Using Chosen_Distributor column, 5 boards + 2 spares
python3 <skill-path>/scripts/bom_manager.py order bom/bom.csv -o bom/orders/ --boards 5 --spares 2
# Or quick single-distributor order
python3 <skill-path>/scripts/bom_manager.py order bom/bom.csv --distributor digikey
--boards multiplies all quantities. --spares adds a flat extra per line after multiplication. --distributor bypasses Chosen_Distributor — generates an order for all parts with that distributor's PN.
Comma-separated PNs (accessories) are auto-split into separate order lines. DNP parts excluded. The script produces one file per distributor in the correct upload format (see references/ordering-and-fabrication.md for format details).
Present the order summary and let the user review/edit before ordering.
Cost estimate: After generating order files, query pricing from distributor APIs at the order quantity and present a total per distributor. See references/ordering-and-fabrication.md for the cost summary template.
Real projects have BOM quirks that don't fit neatly into standard fields. These are the things that get lost between design and ordering — a connector that's only for prototyping, a cable shared between two boards, a part that needs to be ordered from a specific vendor lot. Actively look for these during BOM analysis; don't wait for the user to mention them.
The BOM Comments symbol property (canonical name) captures per-component freeform notes. It flows into the Notes column in the exported CSV. The script recognizes many aliases: BOM Notes, Ordering Notes, Assembly Notes, Notes, Remarks, Comment, and underscore/space variants.
When to suggest adding BOM Comments:
Example values:
"Proto only — DNP in production"
"Shares ribbon cable with power board — don't double-order"
"Must be Murata GRM series, no substitution (validated for EMI)"
"Hand-solder after reflow — temperature sensitive"
"Order 10% extra — fragile QFN rework difficult"
"Use 10K for rev A, 4.7K for rev B"
"Mating connector: Molex 39-01-2040 on cable side"
The schematic symbol property is the best place for per-component notes, but projects scatter this information everywhere. Check all of these:
Schematic text annotations — free text placed on the schematic sheet. The kicad skill's analyzer extracts these as text_annotations. Look for notes near components about ordering, assembly, or variants.
Title block comments — the title block has numbered comment fields. Sometimes used for board-level BOM notes ("All passives 0402 unless marked", "Order from DigiKey for proto").
Project README / docs — look for README.md, docs/, bom/README.md, or any text file mentioning parts, ordering, or assembly. These often contain the highest-level BOM decisions.
Existing BOM CSV Notes column — if a bom.csv already exists, read the Notes column. The user may have added notes there that aren't in the schematic.
Project-level config (.kicad-happy.json) — preferred_suppliers sets sourcing priority, bom section sets field naming and grouping conventions. See skills/kicad/references/config-reference.md for the full schema.
Schematic symbol Description field — sometimes used for assembly notes rather than part description (e.g., "100nF bypass - place close to U3 pin 4").
KiCad custom fields with non-standard names — fields like Assembly, Order, Variant, Config, SKU may contain BOM-relevant info. The analyzer flags these as unrecognized_fields.
DNP with context — a DNP component may need a note about why it's DNP and when to populate it. KiCad's DNP flag is boolean — the reason belongs in BOM Comments.
When a project has multiple boards (e.g., main board + daughter board, or sender + receiver):
Some project-specific items aren't on the schematic but need ordering alongside the BOM. Commonly forgotten:
Track these as rows in the BOM CSV with Reference = -- and a Note, or in a separate bom/non-bom-items.csv. Mention them separately in cost estimates.
When generating reports or order summaries, always surface BOM comments prominently — they're the designer's voice about exceptions and gotchas. Don't bury them. In the order summary, list any component with a BOM comment separately after the main table so the user sees them before clicking "order."
| Imperial | Metric | KiCad Footprint |
|---|---|---|
| 0201 | 0603 | R_0201_0603Metric |
| 0402 | 1005 | R_0402_1005Metric |
| 0603 | 1608 | R_0603_1608Metric |
| 0805 | 2012 | R_0805_2012Metric |
| 1206 | 3216 | R_1206_3216Metric |
Replace R_ with C_ or L_ as appropriate. Prefix with Resistor_SMD:, Capacitor_SMD:, etc.
When the schematic changes between revisions, compare the old and new BOM to identify added, removed, and changed parts. Highlight which new parts need sourcing.
Generates an HTML page showing component locations on the PCB — essential for hand-assembly.
pip install InteractiveHtmlBom
generate_interactive_bom board.kicad_pcb \
--dest-dir bom/ --name-format "%f_ibom_%r" \
--extra-fields "MPN,Manufacturer,DigiKey,Mouser,LCSC" \
--group-fields "Value,Footprint,MPN" \
--checkboxes "Sourced,Placed" --dnp-field "DNP" --no-browser
Read these when you need detailed lookup data:
references/kicad-fields.md — field definitions, aliases, S-expression format, part number patternsreferences/ordering-and-fabrication.md — distributor paste formats, gerber export, CPL, cost templatesreferences/part-number-conventions.md — detailed analysis of naming patterns across 56+ real projectsjlcpcb or pcbway skill)The BOM and distributor skills create files in the project tree. Know what they are so you can clean up or .gitignore them.
| File/Dir | Created By | Purpose | Keep in git? |
|---|---|---|---|
datasheets/ | DigiKey, LCSC, element14, Mouser sync scripts | Downloaded PDF datasheets | No — large binaries, re-downloadable |
datasheets/manifest.json | Datasheet sync scripts | Tracks download status per MPN (legacy name: index.json) | No — regenerated by sync |
bom/bom.csv | bom_manager.py export | BOM tracking spreadsheet | Yes — user-curated data |
bom/orders/*.csv | bom_manager.py order | Per-distributor order upload files | No — regenerated before each order |
*.YYYYMMDD_HHMMSS.bak | edit_properties.py --backup | Schematic backup before edits | No — use git instead |
The kicad skill also creates analyzer JSON and design review markdown reports with user-chosen filenames — see its "Generated Files" section for tracking and cleanup guidance.
| File | Location | Purpose |
|---|---|---|
digikey_token_cache.json | System temp dir | OAuth token cache (9-min TTL, mode 0600) |
manifest.tmp | datasheets/ | Atomic write staging — renamed to manifest.json, never persists |
# Remove downloaded datasheets (re-downloadable)
rm -rf datasheets/
# Remove order files (regenerate before ordering)
rm -rf bom/orders/
# Remove schematic backups
rm -f *.bak
# Remove KiCad analyzer/report files (filenames vary — check project instructions file)
# BOM skill working files
datasheets/
bom/orders/
*.bak
Keep bom/bom.csv tracked — it contains user-curated data (Chosen_Distributor, Validated, Notes) that can't be regenerated from the schematic alone.
AltMPN field for critical partsBOM Comments symbol property for ordering/assembly quirks that don't fit in standard fields. Flows into CSV Notes column. Check schematic text annotations, README, and existing CSV notes for scattered BOM info too.