Download

name: adom-symbol description: Use when the user asks to "create a KiCad symbol", "adom-symbol", "adom symbol", "create a Fusion 360 symbol", "make a schematic symbol", "create a .kicad_sym", "make an EAGLE .lbr", "design a component symbol", "build a symbol for [part name]", "make a symbol and send to KiCad", "send symbol to Fusion 360", or wants to visualize a KiCad symbol in a Hydrogen webview. Covers the full workflow from symbol creation to preview to delivery to local KiCad or Fusion 360 Electronics.

Schematic Symbol Creator

Create professional schematic symbols, preview them interactively in a Hydrogen webview, iterate with the user, and deliver to their local KiCad or Fusion 360 Electronics via Adom Desktop.

Supported output formats:

  • KiCad (.kicad_sym) — native KiCad symbol library
  • Fusion 360 Electronics (.lbr) — EAGLE XML library for Fusion's Electronics workspace

User Preferences

The skill stores user preferences in /home/adom/.claude/skills/adom/preferences.json. These control EDA tool, pin layout style, chip name display, distributor part number, and delivery target.

Step 0: Check Preferences (on first invocation)

At the start of every symbol creation session, read the preferences file:

import { readFileSync } from 'fs';

let prefs;
try {
  prefs = JSON.parse(readFileSync('/home/adom/.claude/skills/adom/preferences.json', 'utf-8'));
} catch {
  prefs = { edaTool: 'kicad', pinLayout: 'left-right', chipNameCentered: false, partNumber: 'none', deliveryTarget: 'webview' };
}

If the file contains only defaults (edaTool is "kicad" and deliveryTarget is "webview" — i.e. the user has never customized anything), let the user know:

  1. Tell the user: "Using default symbol preferences — EDA tool: KiCad, pin layout: left-right. You can update /home/adom/.claude/skills/adom/preferences.json to change these settings, or we can proceed with the defaults."
  2. Then proceed with symbol creation using whatever preferences are currently set — do NOT block on the user changing settings

Preference values and their effects:

Preference Values Effect
edaTool kicad, fusion360, altium, cadence, tscircuit, easyeda, other Controls primary output format and delivery target
pinLayout left-right, all-sides left-right: pins on left and right only (default Adom style). all-sides: pins on left, top, right, and bottom
chipNameCentered true, false If true, add a centered text element with the chip name in the middle of the symbol body (vertically centered) so it's always visible even when zoomed out
partNumber none, mouser, digikey, jlcpcb If not "none", add a property field for the specified distributor's part number. Research and fill it in during Step 1
deliveryTarget webview, desktop, both webview: preview in Hydrogen webview first, only send to desktop when asked. desktop: send directly to desktop EDA after lint/validate pass. both: preview in Hydrogen webview AND send to desktop in parallel

KiCad Service

All service-kicad operations (SVG export, linting, STEP/GLB export) are served by service-kicad — the shared headless KiCad container. Always shell out to the service-kicad CLI, never call its HTTP endpoints directly:

service-kicad sym svg Device R                  # SVG for a stock symbol
service-kicad sym svg my_lib MY_PART --out out.svg
service-kicad health                            # sanity check

The CLI has the production URL baked in at build time (bakes via SERVICE_KICAD_URL env or service.json::url); KICAD_SERVICE_API overrides for dev. No env var is needed on a normal install. See service-kicad skill for the full command surface + install prompt.

Troubleshooting

If service-kicad health doesn't return {"ok":true,...}:

  • Exit 2 (unreachable): container is down. Fall back gracefully — .kicad_sym file can still be written; skip SVG-dependent steps (lint/preview) and tell the user.
  • Exit 3 (auth): Adom-platform JWT expired. Re-authenticate via adom-cli auth refresh.
  • Exit 4 (service error): look at the stderr — usually a malformed input. Retry with a service-kicad-validated file.

If the binary itself is missing: paste the service-kicad install prompt into Claude Code. Browser-side callers that can't shell use /home/adom/project/gallia/viewer/kicad-api-client.js — it reads $KICAD_SERVICE_API from the page's runtime config.

Symbol Categories

Not all symbols are ICs with rectangular bodies. The skill handles two categories:

Category A: ICs / Chips (rectangle body)

Multi-pin ICs like microcontrollers, op-amps, voltage regulators, battery management ICs. These get a rectangular body with pins on the sides, group labels, and the full Adom style treatment. This is the default path described in the rest of this skill guide.

Category B: Discrete Components (standard schematic shapes)

MOSFETs, BJTs, diodes, LEDs, resistors, capacitors, inductors, crystals, etc. These use standard schematic symbol shapes (transistor gates, diode triangles, resistor zigzags) that engineers expect to see. Do NOT draw these as rectangles.

For discrete components, always use KiCad's standard library symbols as the baseline:

import { symSearch, symGet } from '/home/adom/gallia/viewer/kicad-api-client.js';

// 1. Search for the part or its type in KiCad's standard libraries
const results = await symSearch('AO3400A');  // exact part number
// If no exact match, search by type:
// await symSearch('NMOS');  or  await symSearch('Q_NMOS_GDS');

// 2. Get the best matching symbol as .kicad_sym content
const baselineSym = await symGet(results[0].library, results[0].symbol);
// Returns a complete .kicad_sym file with the correct graphical shape

Workflow for discrete components:

  1. Search the KiCad service for the standard symbol (symSearch)
  2. Download the baseline .kicad_sym (symGet) — this has the correct graphical shape (gate arrows, diode triangles, etc.)
  3. Customize the baseline:
    • Update (property "Value" ...) to the specific part number
    • Update (property "Footprint" ...) to the correct package
    • Update (property "Datasheet" ...) with the datasheet URL
    • Add (property "Manufacturer" ...) and (property "Description" ...)
    • Update pin numbers if they differ from the generic symbol (check the datasheet!)
    • Change (generator "kicad_symbol_editor") to (generator "adom")
  4. Create metadata — same -metadata.json format with pin descriptions
  5. Preview — the viewer handles both rectangular and non-rectangular symbols via SVG export

Common standard symbol names in KiCad libraries (full tables including MOSFET, BJT, diode, resistor, capacitor, crystal) and reference designator prefixes (Q, D, R, C, L, Y): see symbol-format-reference.md § Discrete component library lookup tables.

If symSearch finds the exact part number, use that directly. If only a generic symbol exists (e.g., Q_NMOS_GDS), verify pin numbers match the actual part's datasheet before using it as a baseline.

Workflow Overview

0. Check prefs  →  1. Research  →  2. Create symbol folder & files  →  3. Lint  →  4. Preview / Deliver  →  5. Iterate

Delivery behavior depends on deliveryTarget preference:

  • webview (default): After every symbol change, preview in a Hydrogen webview tab. Only send to desktop EDA when the user explicitly asks.
  • desktop: After lint/validate pass, send directly to the user's desktop EDA (based on edaTool). Still preview in a Hydrogen webview for iteration.
  • both: After lint/validate pass, preview in a Hydrogen webview AND send to desktop EDA in parallel.

IMPORTANT: After every symbol change, ALWAYS preview in a Hydrogen webview regardless of delivery target. The delivery target controls whether the desktop EDA also gets an automatic copy.

Symbol Creator Service (Preferred Path)

A local HTTP API service at port 8781 handles all deterministic work: .kicad_sym generation, SVG theming, SymView (interactive viewer HTML) generation, lint, validate, and delivery. Claude's role is to research the part and call the service with structured data.

Service location: /home/adom/gallia/symbol-creator/

HTTP API (all calls go through curl to localhost:8781, no MCP):

Endpoint Method Purpose
/sym/create POST Generate .kicad_sym + SymView from structured pin data
/sym/preview POST Re-preview an existing symbol in the Hydrogen webview
/sym/lint POST Run SVG-based visual linter
/sym/validate POST Check artifact completeness
/sym/search POST Search KiCad standard library for baseline symbols
/sym/deliver POST Send to desktop KiCad or Fusion 360
/sym/samples GET List built-in sample symbols
/sym/sample POST Preview a sample symbol

Example: curl -s -X POST http://localhost:8781/sym/lint -H "Content-Type: application/json" -d '{"symbolName":"RP2040"}'

The service enforces all branding rules (dark theme, Adom purple group labels, gradient body fill, pin tooltips, hit zones) so symbols are consistent every time. See symbol-creator/README.md for full API docs.

SymView is the name for the branded interactive viewer HTML generated by the service.

Sample Symbols & SymView Tour

For demo/tour workflow (NE555 and S32K344 samples, region zoom commands, what to point out): see viewer-and-delivery-reference.md § Sample Symbols & SymView Tour.

Live viewer & layout studio (adom-symbol serve)

adom-symbol serve opens an AI-drivable viewer over a whole chip-fetcher library. The Layout studio is always open (right side); a chip-library rail (with project filters, ↑/↓ nav) is on the left. From the studio you can:

  • pick the source (auto-grouped ds2sf, or any manufacturer / Altium / Fusion / KiCad library variant), the pin layout (left-right / all-sides) + grouping;
  • choose the 3D-chip overlay style (off / shaded iso / thin / bold / blue / teal / dark) and size, and where the chip name shows (on the chip, in the symbol, both, or hidden);
  • place the Reference + chip-name designators: Auto-place centres both clear of the body and pins; Manual gives each label a drag-outline you drop exactly where you want — it re-renders live and auto-saves per-chip. ↶ Undo (or Ctrl/⌘+Z) steps back any change;
  • Send to desktop KiCad / Fusion 360 / Altium / OrCAD.

Per-symbol layout (incl. dragged label positions) persists to each chip's info.json and bakes into its .kicad_sym on save. Reset un-pins a chip and restores the vendor original. Browsing/viewing a chip never mutates it — only a deliberate edit saves.

Symbol Folder Structure

Every symbol gets a dedicated folder under the project schematics directory:

/home/adom/project/project-content/schematics/symbols/
  PART_NAME/
    PART_NAME.kicad_sym           # The KiCad symbol file (native format)
    PART_NAME-metadata.json       # Pin descriptions + part info (feeds Hydrogen webview)
    PART_NAME.svg                 # SVG export via KiCad service
    PART_NAME-viewer.html         # SymView — interactive symbol viewer HTML
    README.md                     # Research summary, pin table, notes

NEVER use /tmp/ for symbol files. Always create and work in the symbol's project folder so the user can reference everything later.

Metadata JSON Format

The -metadata.json file persists all pin descriptions and part info so the Hydrogen webview can be regenerated without re-researching:

{
  "symbolName": "PART_NAME",
  "manufacturer": "Texas Instruments",
  "package": "TQFP-48",
  "description": "Short description of the part",
  "datasheetUrl": "https://www.ti.com/lit/ds/symlink/part.pdf",
  "pinCount": 48,
  "pinDescriptions": {
    "PIN_NAME": "Engineering-grade description of pin function...",
    ...
  },
  "groupDescriptions": {
    "GROUP LABEL": "Description of this functional group and how its pins work together...",
    ...
  }
}

Step 1: Research the Part

Before creating a symbol, gather accurate pin information:

  • Search the web for the part's datasheet (pin table, package, pin functions)
  • Identify every pin: number, name, electrical type, and functional group
  • Note the package type (e.g., TQFP-48, VSSOP-8, SOT-223)
  • Collect metadata: manufacturer, datasheet URL, description
  • If partNumber preference is not "none": Search for the distributor part number on the specified distributor's website (Mouser, DigiKey, or JLCPCB). Add it as a property in the .kicad_sym file:
    • Mouser: (property "Mouser" "XXX-XXXXXXX" (at 0 0 0) (effects (font (size 1.27 1.27)) hide))
    • DigiKey: (property "DigiKey" "XXX-XXXX-ND" (at 0 0 0) (effects (font (size 1.27 1.27)) hide))
    • JLCPCB: (property "JLCPCB" "CXXXXXX" (at 0 0 0) (effects (font (size 1.27 1.27)) hide))

Step 2: Create the Symbol Folder and Files

2a. Create the folder

mkdir -p /home/adom/project/project-content/schematics/symbols/PART_NAME

2b. Create the metadata JSON

Write the -metadata.json file FIRST with all pin descriptions, group descriptions, and part info. This is the single source of truth for the Hydrogen webview hover data — both pin tooltips and group label tooltips are driven from this file.

2c. Create the .kicad_sym file

Full S-expression file format template (kicad_symbol_lib wrapper, property fields, rectangle, pin format): see symbol-format-reference.md § .kicad_sym file format template. KiCad's parser does NOT support comments.

2d. Create the README.md

Required — do not skip. The README is the human-readable record of the symbol. Generate it with:

  • Part name, manufacturer, package
  • Datasheet link
  • Pin table (number, name, type, group, description)
  • Any research notes, application tips, or design considerations
  • Link to the SymView HTML using an absolute Adom URL (see adom-api skill for URL format)

2e. Export SVG and generate SymView

After linting (Step 3), export the SVG via the KiCad service and generate the SymView HTML. Both go in the symbol folder.

Coordinate System and Pin Reference

Coordinate system (Y-up), pin angle table (0/90/180/270), and pin electrical types table (power_in, input, bidirectional, etc.): see symbol-format-reference.md § Coordinate system, § Pin angles, and § Pin electrical types.

Adom Symbol Style

Group pins by function with 7.62mm (3 grid-step) gaps between groups.

By default render composites the white 3D-chip outline + lasered name into the symbol body (and emits the outline contract adom-lbr consumes). The why + mechanics: docs/default-symbol-3d-outline.md.

Pin placement depends on the pinLayout preference and optional per-pin side overrides:

Explicit Pin Side Override

Any pin can specify side: 'left' | 'right' | 'top' | 'bottom' to force placement on a specific side, overriding the auto-placement logic. When all pins in a group share the same side value, the entire group is placed on that side. This is useful for:

  • Balancing symbol dimensions (moving a bulky group to top/bottom)
  • Placing power/ground on top/bottom even in left-right layout mode
  • Achieving a specific physical layout that matches the datasheet pinout

If no side is specified (or pins within a group have mixed/no side values), the auto-placement heuristic below applies.

pinLayout: "left-right" (default)

Place pins ONLY on the left and right sides:

  • Left side: Inputs (analog sense, ADC, sensors, data in), ground (VSS/GND)
  • Right side: Power supply (VCC, regulators), outputs, control, communication, protection
  • Avoid bottom pins — bottom pins add rotated text that clutters the symbol
  • Avoid top pins — rotated vertical text from top pins overlaps with side pin names at corners; prefer placing power pins on the right side instead

pinLayout: "all-sides"

Place pins on all four sides for a more compact symbol:

  • Left side: Inputs (analog, ADC, sensors, data in)
  • Right side: Outputs, control, communication
  • Top side: Power supply (VCC, VDD, regulators)
  • Bottom side: Ground (VSS, GND), thermal pad, NC pins
  • Top/bottom pins use angles 270 (top) and 90 (bottom) — pin names render vertically
  • Ensure body is wide enough that vertical pin names don't overlap with side pin names
  • The generator adds extra body clearance proportional to the longest top/bottom group label and pin name text, so vertical text fits inside the body without clipping
  • Top group labels use justify right (text extends downward into body); bottom use justify left (text extends upward into body) — NEVER the reverse, or text will clip outside the body edge

Body Top Margin

Leave at least 1.5mm between the body top edge and the topmost group labels. The group label text (0.762mm font) needs clearance so it doesn't get clipped by the body edge. Formula: body_top = top_label_Y + 1.8 (minimum).

Body Bottom Margin

The body bottom edge should be 2.54mm below the lowest pin — just enough breathing room without wasting space. The Value property text is placed 2.54mm below the body bottom edge (outside the body). The Reference property is placed above the body top edge.

IMPORTANT: By default, the .kicad_sym file must NOT contain any centered text elements, separator lines, or description text inside the body rectangle. KiCad auto-renders the Value and Reference properties at their designated positions. Adding centered text causes overlap.

Exception — chipNameCentered: true: If the user has enabled this preference, add a centered text element with the chip/part name inside the body rectangle, vertically centered. This makes the part identifiable even when zoomed out. Use a text element in the _0_1 graphics sub-symbol:

(text "PART_NAME" (at 0 {body_center_y} 0)
  (effects (font (size 1.27 1.27) (color 100 100 100 1)) (justify center))
)

Use a muted gray (color 100 100 100 1) so it doesn't compete with pin names or group labels.

Sizing Formula and Pin Group Label Placement

Body sizing formula and pin group label (text) element format, color, alignment, and inter-group gap rules: see symbol-format-reference.md § Body sizing formula and § Pin group label placement.

CRITICAL: No Overlapping — Ever

Nothing in the symbol may overlap anything else. This is a hard rule with zero exceptions:

  • Pin names must not overlap other pin names
  • Pin numbers must not overlap adjacent pin numbers
  • Group labels must not extend past body edges (top, bottom, left, or right)
  • Pin name text must not extend past body edges
  • Left-side and right-side pin names must not collide in the body center
  • Top/bottom pin names (rendered vertically) must not collide with side pin names at corners
  • The body must be sized large enough to contain ALL text elements with clearance

The sym-gen.js generator handles this automatically with:

  • Extra body clearance when top/bottom pins exist (proportional to longest label/name text)
  • Correct text justification for rotated labels (top: justify right = text extends into body; bottom: justify left = text extends into body)
  • 0.1mm pin entry inset from body edge to prevent KiCad text rendering overshoot

If the lint endpoint reports ANY name-area-invasion, body-top-clipping, or pin-name-collision errors, the symbol MUST be fixed before delivery. Increase body size, adjust pin spacing, or modify group layout until lint passes with 0 errors.

Final Checks

After placing all pins, do a final pass to verify:

  • Side pin names from left and right must not collide in the middle of the body
  • Pin numbers (outside the body) must not overlap with adjacent pin numbers
  • Group labels have at least 1.5mm clearance from the body top edge
  • Top/bottom group labels extend INTO the body (not outside)
  • If overlaps exist, widen the body or increase spacing between affected pins

Pin Descriptions

Write rich, engineering-grade descriptions for every pin (1-3 sentences each):

  • Explain the pin's function and electrical characteristics
  • Include recommended external components (capacitor values, resistor values)
  • Note voltage ranges, current limits, or special connection requirements
  • Use Unicode for units: Ω (U+03A9), µ (U+00B5), ± (U+00B1), — (U+2014)

Store descriptions in the -metadata.json file under pinDescriptions. Load them from there when generating the Hydrogen webview.

Group Descriptions

Write a description for every pin function group (2-4 sentences each):

  • Explain the group's role in the overall IC architecture
  • Summarize how the pins in the group work together
  • Note key external component requirements or design considerations
  • Mention relationships to other groups where relevant

Store descriptions in the -metadata.json file under groupDescriptions, keyed by the exact group label text (e.g., "CELL SENSING", "FET DRIVE"). The Hydrogen webview shows these as hover tooltips on the dark red group labels, styled with a warm red title and "Function Group" badge.

Step 3: Lint and Validate the Symbol

After creating or modifying a .kicad_sym file, run both the SVG-based linter and the artifact validator before previewing:

3a. Lint (visual correctness)

Call lintKicadSymbol from /home/adom/gallia/viewer/kicad-lint.js. Lint error codes (group-label-gap, pin-name-collision, pin-number-overlap, name-area-invasion, body-top-clipping) and the JS call pattern: see symbol-format-reference.md § Lint error codes.

Fix all errors before previewing. Re-run after each fix.

3b. Validate (artifact completeness)

Call validateSymbolFolder from /home/adom/gallia/viewer/kicad-validate.js. Validate error codes (missing files, pin-desc-missing, group-desc-missing, pin-count-mismatch, stale description warnings): see symbol-format-reference.md § Validate error codes.

IMPORTANT: The validator fails if any required artifact is missing. Create ALL files (metadata, .kicad_sym, README, SVG, SymView HTML) before the validate step passes. Run lint + validate together at every checkpoint.

Step 4: Export Artifacts, Preview, and Deliver

ALWAYS preview after every symbol change.

Delivery depends on the deliveryTarget preference:

  • webview (default): Preview in a Hydrogen webview only. Desktop delivery happens later in Step 6 when user asks.
  • desktop: Preview in a Hydrogen webview, then also auto-deliver to the user's desktop EDA (based on edaTool pref).
  • both: Preview in a Hydrogen webview AND deliver to desktop EDA in parallel.

When edaTool is kicad, use Step 6a for desktop delivery. When edaTool is fusion360, use Step 6b. For other EDA tools (altium, cadence, tscircuit, easyeda, other), generate the .kicad_sym file as primary output and inform the user they'll need to import it into their EDA tool manually.

4a. Export SVG

Code: see viewer-and-delivery-reference.md § Export SVG code. Use symExportSvg for a custom .kicad_sym file, or symExportSvgByName for a standard library symbol (no file needed).

4b. Generate SymView from metadata

Code: see viewer-and-delivery-reference.md § Generate SymView from metadata. CRITICAL: load -metadata.json and pass pinDescriptions and groupDescriptions to generateSymbolViewer(). Without these, hover tooltips are empty.

4c. Open in Hydrogen webview

Code: see viewer-and-delivery-reference.md § Open in Hydrogen webview. The service writes the SymView HTML to disk and calls adom-cli hydrogen webview open-or-refresh with a proxy URL pointing to GET /viewer/{name} on port 8781.

Viewer vs Native KiCad

The .kicad_sym file is 100% valid native KiCad format. The Hydrogen webview uses a modern Adom-branded dark theme (NOT the old-school KiCad light style). See the brand.md skill guide for the full color palette and design system.

Viewer Style (Modern Adom Theme)

Full color values (background, pin wires, hover colors, group labels, tooltips, info bar), pin hover hit area implementation (IC vs discrete), sticky tooltip interaction, tooltip positioning algorithm, Pin Data Sourcing, Wiki Edit Icon with HTML+CSS, and Viewer Features Summary: see viewer-and-delivery-reference.md.

Key points:

  • Background #0d1117, pin wires teal #00e6dc on hover, group labels Adom purple #8C6BF7.
  • Two hit areas per pin: wire hit area + pin name hit area (for ICs). Discrete symbols use getBBox() on injected labels.
  • Tooltips: frosted glass, click-to-pin sticky mode, viewport-clamped positioning.
  • Info bar must include a "Pin Source" clickable datasheet link.
  • Every Hydrogen webview must include a "Suggest edit" button linking to the Adom Wiki component edit page.

4d. Visual Verification (zoom + screenshot loop)

After opening a symbol in the Hydrogen webview, always self-verify using the zoom-to-region + screenshot loop. Never just open and tell the user "done" — inspect the result yourself.

How it works:

The SymView supports programmatic zoom via JS eval on the Hydrogen webview. Use adom-desktop browser_screenshot to capture the webview after each zoom, using the tab named "SymView: {name}".

Zoom JS eval commands, available regions, and per-region verification checklist: see viewer-and-delivery-reference.md § Sample Symbols & SymView Tour.

Workflow after every symbol change:

  1. curl -s -X POST http://localhost:8781/sym/preview -H "Content-Type: application/json" -d '{"symbolName":"PART_NAME"}' to open / refresh the SymView in the Hydrogen webview
  2. sleep 3 (let it load)
  3. Zoom to top-leftadom-desktop browser_screenshot → check labels
  4. Zoom to top-rightadom-desktop browser_screenshot → check labels
  5. Zoom to bottomadom-desktop browser_screenshot → check labels
  6. Zoom to fitadom-desktop browser_screenshot → final full-symbol screenshot for the user
  7. If ANY overlap or clipping is found: fix in sym-gen.js or pin data, re-run from step 1

Do not skip this loop. The user expects pixel-perfect results. Catching issues yourself saves back-and-forth.

Step 5: Iterate with the User

Show the symbol in the Hydrogen webview and ask for feedback on:

  • Pin grouping and arrangement
  • Missing or incorrect pins
  • Description quality
  • Overall aesthetics

Regenerate and redisplay in the Hydrogen webview after each round of changes. Update all artifacts (SVG, SymView HTML, metadata) in the symbol folder after each change. After each round, re-run both lint and validate to ensure nothing fell out of sync.

Step 6a: Deliver to Local KiCad (only when user asks)

Do NOT send to KiCad automatically. Only send when the user explicitly asks to install/send the symbol to their local KiCad.

Pre-delivery lint + validate check

Run both linter and validator one final time before sending. Do not send if either fails.

Close existing Symbol Editor, then install and open

Always close the Symbol Editor before installing — if a previous symbol is open, openAfterInstall won't switch to the new one. Full JavaScript code (CONDUIT endpoint, close_symbol_editor command, install_symbol with fileContent base64 field): see viewer-and-delivery-reference.md § KiCad install_symbol code.

Key: The base64 field MUST be named fileContent (not fileData).

Step 6b: Deliver to Fusion 360 Electronics (only when user asks)

Do NOT send to Fusion 360 automatically. Only send when the user explicitly asks.

This converts the KiCad .kicad_sym into an EAGLE .lbr, sends it to the desktop, and opens it in Fusion 360's Electronics Library editor.

Convert KiCad .kicad_sym to EAGLE .lbr

The conversion is a direct coordinate mapping — KiCad and EAGLE both use mm with Y-up. Pin type mapping table (KiCad → EAGLE direction), pin rotation mapping table, pin length mapping, NC pin @-suffix convention, and the full .lbr XML template: see viewer-and-delivery-reference.md § EAGLE .lbr format.

Send to desktop and open in Fusion 360

Save the .lbr to the symbol folder, then use adom-desktop:

1. Write /path/to/PART_NAME/PART_NAME.lbr
2. send_files  (filePaths: ["/path/to/PART_NAME.lbr"], targetApp: "fusion360", destinationFolder: "fusion")
3. fusion_open_lbr  (filePath from destinationPaths[0], symbolName: "PART_NAME", verify: true)

The fusion_open_lbr command:

  • Opens the .lbr in Fusion's Electronics Library editor via Document.newDesignFromLocal
  • Navigates to the specified symbol with EDIT PART_NAME.sym
  • Optionally verifies the library loaded correctly by exporting a script

Important: destinationFolder must be a relative path (e.g. "fusion") — absolute paths are rejected by the desktop app.

Reference: Sample Symbols and Troubleshooting

Sample symbol file paths (TLV1117-33, TXB0102, TXB0104, BQ76952, NE555, AO3400A, etc.) and conduit connection troubleshooting: see viewer-and-delivery-reference.md § Reference: Sample Symbols and § Troubleshooting.

Common Pitfalls

  • No comments in .kicad_sym — KiCad's S-expression parser rejects ;; and # comments

  • Coordinate grid — All pin positions must be on the 2.54mm grid for proper connectivity

  • Pin number accuracy — Pin numbers must match the physical package exactly; verify against the datasheet

  • No centered text in .kicad_sym — NEVER add text elements (name, description, separator lines) inside the body rectangle. KiCad auto-renders the Value and Reference properties at their designated positions. Adding centered text causes overlap.

  • Body top clipping — Group labels at the top edge need 1.5mm+ clearance or they get visually clipped

  • Description overflow — The viewer auto-truncates, but keep descriptions concise (<60 chars) so nothing is lost

  • Unused VC/sense pins — For configurable-series parts (like BQ76952), document how unused inputs should be connected

  • Pin name/number format — CRITICAL for hover tooltips — The SymView pin parser requires the compact inline format for (name ...) and (number ...). Adding nested (effects ...) blocks breaks the regex and silently disables ALL pin hover tooltips (group label tooltips still work, making this easy to miss). Always write pins like this:

    (pin power_in line (at -17.54 5.08 0) (length 2.54) (name "GND") (number "10"))
    

    NOT like this (nested effects — parser fails, no pin tooltips):

    (pin power_in line (at -17.54 5.08 0) (length 2.54)
      (name "GND" (effects (font (size 1.27 1.27))))
      (number "10" (effects (font (size 1.27 1.27))))
    )
    

    KiCad renders pin text at the default size regardless — explicit font effects on name/number are unnecessary and break the viewer.

  • footprint-creator — After creating a schematic symbol, use the footprint-creator skill to create the matching PCB footprint (.kicad_mod). The footprint maps pad numbers to the symbol's pin numbers.
  • A future 3d-model-creator skill will handle STEP/WRL 3D models that attach to footprints.