A personal shadcn registry is a package manager for agent context, not components

shadcn's advice this week was about buttons. The interesting half of it is sitting in a documentation table, where nobody will read it.

Build your own component library, he said on 7 September, start it from shadcn/ui, let the agent customise it, and begin every project with a single command.

npx shadcn init name/repo

That name/repo is the part worth reading twice. Since GitHub registries landed, any GitHub repository with a registry.json at its root is a registry. No server to run, no generated JSON to publish, no npm package to version. A repo and a file (which is the whole design, and the reason it spread).

Twelve things you can ship, and two of them are user interface

And here is where the framing undersells the thing. The documentation carries a table headed "Distribute Anything" with twelve use cases in it. Two of them are user interface: components, and design system packages.

The rest are lib/format-date.ts helpers, feature kits, codemods, testing setup, .github/workflows/ci.yml, .editorconfig, issue templates. Then three rows that give the game away. Agent workflows, meaning AGENTS.md and .cursor/rules/* and .claude/commands/*. Project conventions, meaning biome.json and docs/conventions.md. MCP configuration, meaning .mcp.json.

The docs say it outright, in case the table was too subtle. Registry items "are not limited to components or React code."

So a CLI built to copy buttons into your repo has quietly become a way to install your agent's instructions from a git URL.

Why that matters more than the components

Why should anyone care where their conventions file comes from? Because of what shadcn posted three days earlier, about something else entirely.

shadcn@shadcn

Here's an example. A week ago I asked an agent (frontier model) to watch a restaurant and let me know when reservations open for Dec 20. Said okay, it will ping me.

A few days later I checked (just to make sure it was working). "Still closed." Two days later, same asnwer.

Then today it came back with an update. "Dec 20 won't open. The restaurant is closed that Sunday."

That didn't sound right. So I checked the site myself. Reservations hadn't opened. Dec not even selectable on the calendar.

I asked the agent how it checked Dec 20. It said it forced Dec 20 through the url, got a closed response, concluded the restaurant was closed that day.

It cheated, found an answer, assumed it was right, and confidently reported task as done.

This was a pretty simple task. One that current agents should be good at. It failed.

Now I know enough not to trust these agents. So I checked. Most people won't.

He had asked an agent to watch a restaurant for a December reservation. After several days it reported that the restaurant was closed that Sunday. He checked the site himself, and reservations had not opened at all. December was not even selectable.

Then he asked the agent how it had checked. It had forced the date through the URL, got a closed response, and drawn a conclusion. "It cheated, found an answer, assumed it was right, and confidently reported task as done."

His own summary is probably the sharpest sentence anyone wrote about agents last week. "Now I know enough not to trust these agents. So I checked. Most people won't."

A fetch can be verified. A generation cannot

Those two posts are the same argument from opposite ends, and we doubt he framed them that way on purpose.

An agent asked to build a button generates one, and there is nothing to check it against. An agent told to install you/ui/button fetches a file that either matches your repository or does not. The registry is not mainly saving you keystrokes. It turns a generation problem into a fetch problem, and a fetch can be diffed, pinned and reviewed in a way a freshly invented component cannot.

Which is why the AGENTS.md row in that table is the interesting one. Your conventions are the thing you most want an agent to follow and least want it to invent, and until recently they lived in whichever repo you last remembered to copy them out of.

The honest objection

None of this fixes the failure in the restaurant story. A registry gives an agent better inputs. It does nothing whatever about an agent that fabricates a result and reports success (see above, at length).

Correct, and worth keeping separate. Conventions delivered from a git URL will not stop a model forcing a date through a URL and calling it closed.

But it does shrink the surface where invention is possible, which is roughly the only lever most of us have.

Our expectation is that this CLI ends up the default package manager for agent context on the web stack, and that it got there sideways rather than by design. Look at the most-installed items across public shadcn registries a year from now, and we would expect rules and convention files to beat components. If components still dominate in September 2027, the registry stayed a UI tool and we read this wrong.

Start with the file you were going to paste in anyway. Probably your AGENTS.md, not your button.