UI Thing: shadcn-style Nuxt components you copy into your own project

The component source lands in your repository, not in node_modules

UI Thing is described as a modern set of Nuxt components built with Reka UI and TailwindCSS, inspired by shadcn/ui and shadcn-vue. The important word there is inspired, and the installation flow makes the difference concrete. You initialize the project with one command, and the components end up as source in your own project rather than as a dependency. That is the shadcn model, and it has an obvious upside and an obvious cost. The upside is that you can edit a component without forking a package or fighting a wrapper. The cost is that the library stops being a library once you have copied it, and updates arrive as diffs you have to apply yourself. The documentation lives at uithing.com, and the default branch of the repository is v2, which suggests a second generation of the component set rather than a stable 1.x contract.

Five commands, and add is the one you will use most

The command list is short and each entry does a specific job.

| Command | Description | | --- | --- | | `init` | Install dependencies and configure your project. | | `add` | Add selected components to your project. | | `theme` | Apply a theme to your project. | | `prettier` | Add Prettier config for consistent formatting. | | `shortcuts` | Add keyboard shortcut composables. |

The init command does the setup, and add is the one that pulls in individual components on demand, which is how you keep a project from carrying every component in the set. The theme command applies a theme, the prettier command adds a formatting config, and the shortcuts command adds keyboard shortcut composables. The npm package name is ui-thing, so the commands are invoked through npx, and the README shows the three you will use first.

npx ui-thing@latest init

npm run dev

npx ui-thing@latest add

The theme, prettier and shortcuts commands are in the table but the README does not give their invocation syntax, so check the documentation site for how they are called.

An installable agent skill with two copies to keep in sync

UI Thing also ships an installable uithing agent skill for the open skills ecosystem, and the README gives the command to add it from the repository.

npx skills add https://github.com/BayBreezy/ui-thing --skill uithing

The interesting part is the two-copy arrangement. The installable skill lives in skills/uithing, while the repo-local authoring copy used by Codex lives in .agents/skills/uithing. After updating the source skill you refresh the installable copy with a script.

npm run sync:skills

The package manifest confirms the mechanism, with the sync:skills script pointing at scripts/sync-skills.js. The repository also has a skills-lock.json, a .claude directory, an .agents directory, a .mcp.json file, an AGENTS.md, a CLAUDE.md and a .husky directory with commitlint.config.js, so the project is set up for agent-assisted work at the level of the repo itself. The two-copy design is a known cost of that setup: the source of truth is one directory, and the published artifact is another, and a forgotten sync means the published skill lags the code.

The stack underneath: Nuxt, Tailwind, Reka UI and a heavy editor dependency list

The credits section names the projects behind the library: shadcn/ui, Reka UI, TailwindCSS for Nuxt, Nuxt itself and Nuxt UI. The dependencies in the manifest show how much of the weight comes from the editor components rather than from the styling. There is a long list of @tiptap extension packages, each pinned at version 3.32.0, covering color, highlight, link, list-item, subscript, superscript, table, table-cell, table-header, table-row and text-style. Alongside that sit @tanstack/vue-table, @fullcalendar/vue3, @internationalized/number, @nuxt/kit at 4.6.2 and @baybreezy/docd. The tips are the tell. A component library whose default dependency set pulls in a full rich text editor with table support is not a minimal set of primitives, and while the point of the add command is that you only install the components you choose, the underlying package still has to carry those entries. The build scripts reflect the scale, with the analyze and build scripts setting a 14 GB old space size for the Node process.

The repository is a full Nuxt application, not just a component folder

The top-level entries describe something larger than a component library. There is an app directory, a content directory with a content.config.ts, a server directory, a modules directory, a data directory, a Dockerfile, a nixpacks.toml and an .env.example that sets a public URL and a Google Analytics id. The manifest scripts show a documentation site generator, with generate:blocks and generate:components scripts that run node scripts/create-blocks.js and node scripts/create-components and then format the output, plus a separate generate:all that runs both. There is an automd script that watches markdown files, and the fmt and lint scripts use oxfmt and eslint. The package is private false and MIT in the manifest, with the author listed as Behon Baker, and the package manager is Bun, visible in the clean script which removes bun.lock and runs bun i.

A multi-stage Dockerfile that keeps secrets out of the image history

The Dockerfile is worth reading because it says how the docs site is built and deployed. It is based on oven/bun for the dependency layer and node:24-bookworm-slim for the rest, with a comment noting that Nuxt needs 24.13.1 or newer per the engines field in the manifest while Bun matches the packageManager entry. The deps stage copies only package.json and bun.lock, sets HUSKY=0 and CI=true, and runs bun install with a frozen lockfile and ignored scripts, so the postinstall hook that runs nuxt prepare does not run before the source is present. The build stage then copies the source and runs the install again, this time with scripts, so vue-demi, sharp and nuxt prepare execute. Build-time values including PUBLIC_URL, GA_ID and NUXT_OG_IMAGE_SECRET are passed as build arguments and set as environment variables in that stage only, and the comment states the reason plainly: they do not live in the final image, so secrets do not end up in the shipped image history. The final runtime is Node plus the self-contained .output directory only.

A licence that the manifest and the repository disagree about

Here is a detail to check before you build on this. GitHub reports the repository licence as a custom one that it cannot classify, and points at the LICENSE file. The LICENSE.md file is present at the repository root. But the package manifest declares the licence as MIT, with the author as Behon Baker and a homepage. So there are two statements about the terms, one in the manifest and one in the file, and the repository classification does not match either. Read LICENSE.md directly and decide from its contents. The rest of the project state is healthy. The repository is not archived, the last push was on 2026-10-19, and the project has no GitHub releases, so the published version history lives on the npm registry rather than on the releases page. The homepage is uithing.com, and the docs are described as complete rather than partial.

Editorial conclusion

UI Thing fits a Nuxt team that wants shadcn-style source-owned components with Tailwind and Reka UI underneath, and that would rather own the code in its repository than depend on a component package. It does not fit a Vue project outside Nuxt, since the whole toolchain assumes Nuxt, or a team that wants versioned component updates from a registry. Verify first that the init command produces components you are willing to maintain yourself, read the LICENSE.md file rather than relying on the MIT string in the package manifest, and check the documentation site at uithing.com for which components the add command actually offers before you plan around them.

Frequently asked questions

Official sources

1. BayBreezy/ui-thing on GitHub
2. Issues
3. Project website
4. README