This registry is maintained by me, Patrick Prunty, for my own use cases. It isn't a general-purpose component library and doesn't aim to be one. A component gets in when I've needed it across multiple projects and found it difficult enough to build on more than one occasion.
The license is MIT, so you're free to use any of these components however you like. What I ask in return is a favour rather than a requirement: tell me what worked and what didn't. If you find a way to generalise one of these components to a more pressing product use case, share the details so we can refine it together within this registry. Those contributions make the component better for everyone who uses it, including me.
What I accept and what I don't
If it's already done well by Base UI or shadcn, I don't want it. Unless yours is a considerable improvement in API or design, please don't bother.
How to contribute
Reach out to me via email or X, or open an issue before a pull request for anything beyond a small fix. It saves us both time if we agree on the shape of a change first.
For local development:
make run
That installs dependencies and starts the dev server. make check runs what CI runs, and make on its own lists every target.
QA passes
A component gets a QA pass before it ships and again after any bug report, and a pull request that fixes behaviour links the finding it closes. The pass is a skill in the repo, run from Claude Code with Claude in Chrome enabled so it can screenshot the live site:
1/qa-component <slug>
It scripts an editing session against the component's doc page, confirms every root cause against the code rather than the screenshot, and publishes a findings page (repro steps, expected vs actual, the file to look at, a picture) that an engineer can work from cold. Reproduce a finding from its steps before fixing it, and land each fix with a test that runs the same steps.