Col

Sol could not do it himself, so we made Col.

A community-maintained directory for finding the right UI library without losing an afternoon to open tabs.

Request a library · Request a feature · Report a bug · Contribute

What Col does

Col organizes UI libraries by category, stack, and use case. Search from the homepage, then compare matching libraries in the directory.

• Search by name, keyword, category, stack, or use case.
• Search by component name, and jump straight to that component's official docs.
• Filter libraries without leaving the directory.
• Save useful libraries locally.
• Open the official website or documentation from each listing.
• Find MCP servers and connectors for UI libraries and design tools, and copy setup for your AI client.
• Contribute missing libraries through a focused pull request.

Col catalogs libraries. Libraries can also list the components they document, so you can search by component name — but that list is partial and grows by contribution, so a component missing from Col is not necessarily missing from the library. Col never infers a component from a library's generic tags.

Col also lists integrations in a separate directory at /integrations. An integration is an MCP server, a connector, or both: "MCP server" means you add it to your client's config, and "connector" means you enable it from an AI app's own directory. CONTEXT.md defines these terms, and docs/adr/0001 explains the model.

Run it locally

Requirements: Node.js 20.9+ and npm.

Open the local URL printed in the terminal (usually http://localhost:3000).

Before opening a pull request:

Request something

Use the matching issue form. One focused request per issue makes discussion and review easier.

Request a library

Open a library request when a useful UI library is missing.

Include:

• the library name and official URL;
• what it provides and who it helps;
• its supported stacks;
• the closest Col category and use cases;
• confirmation that it is maintained and publicly accessible.

Search existing libraries, issues, and pull requests first.

Request a feature

Open a feature request for improvements to discovery, comparison, contribution, accessibility, or the library detail experience.

Explain the problem before proposing the interface. Include the expected outcome and any useful references.

Report a bug

Open a bug report with:

• the page or action that failed;
• exact reproduction steps;
• expected and actual behavior;
• browser, operating system, and viewport;
• screenshots, recordings, or console errors when relevant.

Do not include secrets, tokens, private URLs, or personal information.

Add a library with a pull request

Library-only pull requests should be small and should not redesign unrelated parts of the site.

1. Fork the repository and create a focused branch.
2. Add one entry to data/libraries.ts.
3. Reuse the existing category, stack, and use-case values when possible.
4. Keep the description factual and short.
5. Confirm the URL points to the official project.
6. If you add components, verify each one against the library's own docs in data/components.ts.
7. Run npm run build.
8. Open a pull request using the provided template.

The slug must be unique, lowercase, and kebab-case. See CONTRIBUTING.md for the full checklist.

Set addedAt when the library joins the catalog. It shows the "new additions" label for seven days; editing an existing entry should keep its original timestamp.

Adding components

Components live in data/components.ts, keyed by the owning library's slug, so searching "date picker" or "stroke text" finds the libraries that document it and links straight to that component's page.

• name should be spelled the way the library documents it, for example Date Picker.
• aliases are optional extra search terms for what people actually type, such as cmdk for a command palette. Keep them to real search terms, not synonyms for the rest of the index.
• url must be the canonical documentation page for that exact component, on the same domain as the library, and must not be a setup or marketing page.

Coverage is partial and grows by contribution, so add a handful you have checked rather than a long unverified list. Col states this plainly in the UI, so a short accurate list beats a long speculative one.

Adding an MCP server or connector

Integrations live in data/integrations.ts. An entry describes the server once; Col generates the config snippet for each client and the agent prompt.

• A product offered both ways is one entry with both kinds of setup path.
• Never add a credential. For an API key, name the environment variable and link to where the user creates it. Col renders a placeholder in each client's own syntax.

Dedicated library pages

Each library will have a dedicated Col page with:

• a clear overview and best-fit use cases;
• supported stacks and key capabilities;
• official documentation, repository, and installation links;
• useful comparisons and alternatives;
• a copyable setup prompt for coding agents.

Agent setup prompt

Library pages will provide a prompt based on this structure:

When contributing a future detail page, keep the prompt specific to that library and link every installation claim to official documentation.

Project structure

UI components

Application controls use the components in components/ui. Use the existing Button, Input, Tabs, and DropdownMenu before adding another control. Keep product-specific layout and behavior in components/, and keep visual variants in components/ui/ when the standard component does not cover them.

components.json configures shadcn/ui. The components are owned by this repository and may use Radix primitives internally for keyboard and accessibility behavior. Theme colors for those components live in app/globals.css.

Built with

Next.js · React · TypeScript · Tailwind CSS · shadcn/ui · Radix UI · Lucide

Community

Be clear, constructive, and respectful. Contributions are welcome whether you are adding a library, improving metadata, fixing a bug, or making discovery easier.

Col is licensed under the MIT License.