npx shadcn add

Add the registry to components.json. The {name} placeholder is filled in by the CLI — leave it exactly as written.

{
  "registries": {
    "@hoverlab": "https://hoverlab5.netlify.app/r/{name}.json"
  }
}

Then install the design system once, so the tokens every block references actually exist:

npx shadcn add @hoverlab/hoverlab

That writes the light and dark CSS variables, the radius scale and the icon library into your stylesheet. Skip it and blocks will install fine but render against whatever --primary your project already had.

@hoverlab/hoverlab gives you this site’s own look. If you want a different one, there are 5 named presets — each a complete token set covering colour, corner radius, spacing density and the type ramp, in one install.

npx shadcn add @hoverlab/preset-console

These are registry:base items — the same document a shadcn preset code resolves to, published at a URL you can install by name. They are not preset codes: those are minted by ui.shadcn.com/create and only shadcn can issue one, so shadcn apply --preset will not take these. The payload and the effect on your project are the same.

Items are addressed by the same id the catalog uses, so anything you can open on this site you can install by name.

npx shadcn add @hoverlab/hero-split
npx shadcn add @hoverlab/saas-landing-page

A page brings its blocks with it. saas-landing-page declares twelve of them as registry dependencies, so one command writes the route and every section it renders.

The path- items are the 11 guided paths, published as packs. Each one is nothing but a list of registry dependencies, so npx shadcn add @hoverlab/path-landing-page writes all 8 blocks of that path in one pass — and a block fixed here is fixed in every pack that references it, because a pack holds no copies. The paths themselves carry the part a registry item cannot: why each block sits where it does.

Once the registry is in components.json, the shadcn MCP server that ships with CLI v4 can search and install from it without you typing a command — ask for a pricing section from the @hoverlab registry and it resolves the item, its dependencies and its install command on its own.

This sits alongside Hoverlab’s own MCP server, which goes further: it searches all four tiers, scaffolds whole templates, and matches a Figma frame against the catalog. Use the shadcn registry when you want the standard tool; use ours when you want the rest of the ladder.

Both are CORS-open and cacheable, and neither needs a token. If you would rather not use shadcn at all, the same catalog is available through the public API and npx hoverlab.

shadcn search normally downloads a registry’s whole index and filters it in the CLI. At 1,576 items that is a few hundred kilobytes to show six rows, so this registry implements shadcn’s dynamic search instead: the same /registry.json URL takes q, type, limit and offset, matches on our side, and returns the page plus a pagination object.

npx shadcn search @hoverlab -q "pricing"

Nothing to configure — the CLI appends those parameters on its own and uses the results as they come back. You can call it directly too:

curl 'https://hoverlab5.netlify.app/registry.json?q=hero&type=registry:block&limit=5'

An effect is a class and the rules behind it, not a file, so it installs into your stylesheet rather than into components/. The command is the same as everything else:

npx shadcn add @hoverlab/btn-gradient

That writes the rules — including any @keyframes and @property the effect needs — straight into the stylesheet your project already has, and prints the markup to paste. There is nothing to import and no dependency to install: effects are CSS, so they work in React, Vue, Svelte or a plain HTML file.

Templates are not registry items. A template is a whole project rather than a thing you add to one, and npx hoverlab init already scaffolds it — including the config, the routes and the dependencies a shadcn add has nowhere to put.