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
- — reusable Zener packages and entrypoints. This is the primary search mode for schematic reuse.
- — registry symbols/parts with MPN, manufacturer, footprint, datasheet, availability, and . 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:
bash
pcb search -m registry:modules <query> -f json
Use functional queries when the board need is functional:
,
,
,
"automotive high side switch"
.
Search symbols/parts when you need a concrete MPN, footprint, availability, or the package behind a primitive:
bash
pcb search -m registry:components <query> -f json
Use MPN/manufacturer queries when the user named a part:
,
Texas Instruments TPSM336
,
.
Then inspect the candidate API before instantiating it:
bash
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
results to compare physical package, pinout, MPN, stock, price, datasheet, and
. Use
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
entrypoint from the chosen
result directly in the consuming
file.
python
PartModule = Module("github.com/diodeinc/registry/components/<Manufacturer>/<NAME>/<NAME>.zen")
Do not manually edit
to add the dependency. On the next
, the tool will detect the registry import and add the dependency to the package manifest automatically.
Use
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:
bash
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.