registry-search
Registry Search
Find prepared registry content before designing a circuit or choosing a new part by hand.
Use this when working on a board, subsystem, or spec and you need a reusable schematic module, reference design, primitive component package, concrete MPN, symbol, footprint, datasheet, or sourcing signal.
Search Modes
registry:modules— reusable Zener packages and.zenentrypoints. This is the primary search mode for schematic reuse.registry:components— registry symbols/parts with MPN, manufacturer, footprint, datasheet, availability, andmoduleUrl. Use this for concrete part discovery and to find the package behind a symbol.
Do not create, import, or patch component packages in this workflow. If the registry does not contain a suitable result, or the closest result needs even a small package/API/circuit tweak, produce a librarian request.
Search Workflow
Start with reusable schematic content:
pcb search -m registry:modules <query> -f json
Use functional queries when the board need is functional: "usb c source", "3.3v ldo", "128mb spi flash", "automotive high side switch".
Search symbols/parts when you need a concrete MPN, footprint, availability, or the package behind a primitive:
pcb search -m registry:components <query> -f json
Use MPN/manufacturer queries when the user named a part: TPS70933, Texas Instruments TPSM336, USB4105.
Then inspect the candidate API before instantiating it:
pcb doc --package <module-url>@<version>
If docs are incomplete or fail, read the package source from the dependency cache, registry checkout, or sandbox checkout instead of guessing the IO/config interface.
Choosing Results
Prefer the most reusable correct abstraction:
- A higher-level module or reference design that already implements the needed schematic circuit.
- A component package with included support circuitry when that is exactly the intended use.
- A primitive component package when the board genuinely needs only the raw part.
Use registry:components results to compare physical package, pinout, MPN, stock, price, datasheet, and moduleUrl. Use registry:modules results to compare entrypoints, dependencies, dependents, and package descriptions.
Ask only when tradeoffs are real: package size, cost, stock, electrical margin, automotive/industrial grade, interface differences, or user-visible feature choices.
Using Results In A Board
Instantiate the .zen entrypoint from the chosen registry:modules result directly in the consuming .zen file.
PartModule = Module("github.com/diodeinc/registry/components/<Manufacturer>/<NAME>/<NAME>.zen")
Do not manually edit pcb.toml to add the dependency. On the next pcb build, the tool will detect the registry import and add the dependency to the package manifest automatically.
Use pcb doc --package or source inspection for exact IO and configs. Do not infer pin names from search snippets.
After adding the package to a board or module, verify the consuming design:
pcb build <board-or-module-path>
pcb bom <board-or-module-path> -f json
Librarian Requests
When no suitable registry content exists, or a close match needs to be changed before it is safe to use, stop the registry search workflow and prepare a librarian request instead of authoring or patching the package inline.
A good request includes:
- board/subsystem context and why the package is needed
- required function and fundamental schematic topology, if known
- electrical requirements: rails, current, speed, accuracy, protection, temperature, qualification
- physical constraints: package/footprint, height, connector style, pinout constraints, assembly limits
- preferred or user-specified MPNs, manufacturers, and acceptable alternates
- sourcing constraints: region, stock, lifecycle, target cost, approved distributors
- searches tried, candidates rejected, and why they failed
- close registry matches that need tweaks, with the exact missing API, circuit, symbol, footprint, sourcing, or documentation change
- needed deliverable: primitive component, reference-design module, connector module, family selector, or patch to an existing package
Keep the board moving with a placeholder only if the user accepts the risk and the unresolved librarian request is recorded in the spec or TODOs.
More from diodeinc/pcb
datasheet-reader
Read datasheets and technical PDF documents with `pcb scan`. Use when the user gives a local PDF path or an `http(s)` datasheet/document URL, when a task requires reading, summarizing, extracting information from, or answering questions about a datasheet or technical PDF, or when a KiCad symbol / `.kicad_sym` provides a `Datasheet` property to resolve. Run `pcb scan <input>` in bash, treat stdout as the generated `.md` path, then read that markdown file.
813reference-design
Grow a component package into a high-quality, sourceable reusable design in Zener. Use when translating a datasheet, application note, or eval design into circuitry that should live with the component package itself — including checking for existing reusable packages first, extracting evidence, choosing sourceable passives, documenting the design in the `.zen` docstring, and validating with `pcb build`.
799component-search
Search for and add electronic components and reusable subcircuits to a Zener PCB project. Use when designing a board, module, or subsystem and you need a part package, a reusable module, or a component package that may already include application circuitry. Covers `pcb search` (registry:modules, registry:components, web:components) and `pcb new component` for importing web components into a workspace.
787zener-language
Canonical Zener HDL guidance — language semantics, package rules, manifests, stdlib APIs, and authoring idioms. Use when writing, editing, refactoring, or reviewing non-trivial `.zen` code, especially work involving `Module()`, `io()`, `config()`, imports, `pcb.toml`, stdlib interfaces, units, generics, DNP patterns, or validation.
784idiomatic-zener
Style rules and idioms for writing high-quality Zener HDL code. Use when writing, reviewing, or refactoring `.zen` files — modules, reference designs, or board files. Covers DNP patterns, typed configs, voltage checks, component naming, computation style, and common gotchas.
724spice-sim
Adds an ngspice-backed simulation testbench to a Zener `.zen` design. Use when the user asks to simulate a circuit, validate behavior in SPICE, or wire a `spice_model=SpiceModel(...)` into a leaf component. Covers `pcb sim`, `Simulation` property, and ngspice `.control` blocks with `tran`/`PULSE`/`PWL` sources and SVG `hardcopy` output.
292