OPEN SOURCE · MIT

Got a component? Add it to the registry.

VibeKit is community-driven. If you've built a production-grade component for auth, payments, file uploads, search, dashboards — anything reusable across projects — open a PR. We merge weekly.

WHY CONTRIBUTE

Build once. Ship in every project.

A merged component is loaded by every developer using VibeKit — not just yours.

Distribution

Your component gets a permanent doc page at /components/<slug>, indexed by search engines and AI answer engines.

Credibility

VibeKit is opinionated — making the cut signals your component is production-ready, not a weekend hack.

Compounds

Every Claude Code session reads jb-components.md. Your component becomes part of the agent's default toolkit across thousands of builds.

THE PROCESS

From idea to merged in 4 steps.

No bureaucracy. Just a clear schema and a PR template.

  1. 01

    Build & host the component

    Build a working component and publish it to a shadcn-compatible registry (your own domain works — e.g. https://yourdomain.com/r/your-component.json). Verify pnpm dlx shadcn@latest add <url> works on a fresh Next.js 16 project.
  2. 02

    Write a doc page

    Document what the component does. A blog post on your own site or a markdown file in the PR description both work — but it has to exist. Link it via theblogUrl field. This becomes the "Read full guide" button on the component's detail page.
  3. 03

    Open a PR

    Fork the repo, edit web/src/lib/components-data.ts, add your entry using the schema below, and open a pull request. The PR template walks you through the checklist.
  4. 04

    Review & merge

    We review weekly. Most PRs need one or two iterations on copy or schema. Once merged, your component appears at /components/<your-slug> and is loaded by every Claude Code agent reading the registry.
THE SCHEMA

One file. One entry. Done.

All component metadata lives in web/src/lib/components-data.ts. Copy this template, fill it in, and push to a new branch.

web/src/lib/components-data.tsAppend to the components arrayts
{
  slug: "my-component",
  name: "My Component",
  tagline: "One sentence — what it does, who it's for.",
  category: "data", // auth | marketing | data | commerce | files | content | api | forms
  categoryLabel: "Data",
  install: "pnpm dlx shadcn@latest add https://your-registry.com/r/my-component.json",
  blogUrl: "https://your-domain.com/blog/my-component",

  prerequisites: [
    "Next.js 16 + shadcn/ui",
    "PostgreSQL database",
    // anything else that must be set up first
  ],

  envVars: [
    { name: "MY_API_KEY", description: "Where to get it (e.g. service dashboard)" },
    // omit this field entirely if no env vars are needed
  ],

  features: [
    "Bullet point — what it does (a feature, not marketing fluff)",
    "Another bullet",
    "3–6 bullets total is the sweet spot",
  ],

  whenToUse: "One sentence describing the project type or use case where this is the right tool.",
  whenNotToUse: "One sentence describing when a different approach is better.",

  filesAdded: [
    "/route-it-creates",
    "/api/endpoint-it-adds",
    "components/component-name.tsx",
    "Prisma schema additions: ModelName",
    // list every file or route the install command produces
  ],
}

Each field, explained

slugURL-safe identifier. Becomes /components/<slug>. Lowercase, hyphens, no spaces.
nameDisplay name. Title case. Brief — 'JB Better Auth UI' beats 'The JB Better Auth UI Component System'.
taglineOne sentence under 100 characters. What it does + who it's for.
categoryOne of: auth | marketing | data | commerce | files | content | api | forms. Propose a new one in the PR if none fit.
categoryLabelDisplay label for the category tag.
installThe exact command users run. Must be tested on a fresh Next.js 16 project.
blogUrlURL to a doc page explaining the component (your own blog, GitHub README, anywhere accessible).
prerequisitesThings that must exist before installing (database, other components, accounts). Optional.
envVarsEach env var with name + description of where to obtain it. Omit field if none.
features3–6 bullet points describing capabilities. No marketing fluff.
whenToUse / whenNotToUseOne sentence each. Honest about tradeoffs — readers respect that.
filesAddedEvery route, API endpoint, component, and schema change the install creates. This is the most-checked field — be exhaustive.
BEFORE YOU OPEN THE PR

Quality bar.

We review for these. Hitting them is the fastest path to merge.

  • Component is production-ready and documented (not a half-built prototype).
  • Install command works end-to-end on a fresh Next.js 16 project.
  • Schema entry includes every required field (see template below).
  • Files-added list is accurate — every route, API, component, schema change.
  • Env vars are enumerated with where to obtain them.
  • Component category fits one of the existing categories OR you propose a new one in the PR.
  • Component does not duplicate an existing JB component (check /components first).

Ready to ship?

Fork the repo, add your entry, open a PR. We'll review within a week.