Find reusable registry modules and component packages for a board or specification.
Registry Search
Find suitable prepared content before authoring a new reusable package.
Only discover or clone other boards when the user explicitly asks to find or
inspect them; do not search other boards proactively as part of registry
package search. For requested board discovery, use mcp__diode__list_boards with
the workspace name. If inspection is requested, git clone the returned HTTPS
URL outside the current checkout; sandbox DiodeHub authentication is already
configured.
| Need | Command |
|---|---|
| Reusable circuit or entrypoint | pcb search -m registry:modules <query> -f json |
| Concrete MPN, footprint, availability, or package behind a symbol | pcb search -m registry:components <query> -f json |
| Candidate source directory | pcb list -m -json <module-url>@<version> |
Use functional queries for functional needs and MPN/manufacturer queries for
named parts. Read the candidate's source in the reported dir for its public
API; do not infer IO/config names from a search snippet.
Prefer a reusable module or reference circuit that matches the actual need,
then a component with the required support circuitry, or a primitive when only
the raw part is needed. Compare electrical fit, package, pinout, sourcing, and
public API. Use preferred-parts when choosing a concrete MPN. Ask only about
material unresolved tradeoffs.
Instantiate the chosen .zen entrypoint directly in the consuming design.
For example:
PartModule = Module("code.diode.computer/diode/registry/components/<Manufacturer>/<NAME>/<NAME>.zen")
Follow zener-language for dependencies and validation; do not hand-edit
pcb.toml to add the dependency.
If no suitable result exists or a candidate needs a package/API/circuit fix,
use librarian within a registry-authoring task. From board or spec work,
prepare a librarian-dispatch request instead of patching reusable packages
inline.
