# ObsidianUI installs React components as editable source, not as a dependency

> ObsidianUI is a React and Tailwind CSS component library that publishes through the shadcn registry, so a component is copied into your project as source you own, with the same registry serving an llms.txt, Markdown docs and a local MCP server for coding agents.

**Atharvsinh-codez/ObsidianUI** — React & Tailwind CSS Components Library

- Repository: https://github.com/Atharvsinh-codez/ObsidianUI
- Website: https://obsidianui.dev
- Stars: 531 · Forks: 28
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/atharvsinh-codez-obsidianui

## The shadcn registry model, and what lands in your repo

ObsidianUI is a React and Tailwind CSS component library, and the tag line is a design argument as much as a description: design less, ship better. What makes it different from a component package is the delivery mechanism. Components are installed through the shadcn CLI, and the install command names a registry entry on the project's own site:

```bash
npx shadcn@latest add "https://www.obsidianui.dev/r/hover-img.json"
```

and for the interactive prism effect:

```bash
npx shadcn@latest add "https://www.obsidianui.dev/r/v-prism.json"
```

The consequence of that is the thing to understand before you start. A registry install adds editable files to your project, including the styles and local helpers a component needs. You do not add a dependency you have to configure; you get source code in your tree, and from that point it is yours.

That also means the upgrade story is different from a package. There is no version to bump, because the code is already in your repository, and a change upstream arrives as a diff you choose to take. The README does not say the opposite, and it is worth naming the trade explicitly: you get editability and you give up the ability to receive fixes automatically.

## The same registry is the documentation channel and the agent channel

The interesting part of this project is that the registry is not only a distribution channel. The README lists four ways to reach the components, and three of them are aimed at machines rather than people.

The first is llms.txt, the plain text file that describes a site to a language model. The second is the Markdown documentation. The third is the public registry at the site, the same registry.json the shadcn CLI reads. The fourth is the local MCP server, a Model Context Protocol server the repository launches over stdio.

That last one is the most interesting for a team that now writes code with agents. The package manifest has a script for it, npm run mcp, which runs a TypeScript server script, and there is a separate MCP.md in the repository root documenting it. The effect is that a coding agent can look up the component catalogue, its documentation and its install command without a human copying URLs.

The site also exposes the components, the templates, and the documentation as separate sections, and the landing page templates are advertised with a Project One example and a template gallery. So the same source produces a browsable site, a machine readable registry, Markdown pages and an agent endpoint, and the README is explicit that all of it is generated from the component source rather than maintained by hand.

## The repository is set up to be worked on by an agent

ObsidianUI is built with Factory, and the README says it was built with Droid, Factory's software development agent. What matters is not the tool but the structure: the repository is arranged so an agent can take a component from idea to install command, and the source, a docs page, tests and the registry entry are all in one place. The instruction is to clone the repository and build your own components with Droid the same way.

Two files carry that arrangement. AGENTS.md is loaded by Droid at the start of every session, and it sets where primitives, blocks, docs and tests go, forbids hand-editing generated files, and names the checks to run before work counts as done. ACEBUILDER.md and the skills directory hold the design conventions AGENTS.md points to, covering accessibility, colour, layout, typography, transitions and writing.

The workflow the README describes is four steps. You install Droid from its quickstart, clone the repository and start Droid in it, describe the component you want, and then review the changes and run the dev server to look at the new docs page. The example prompt given for the agent is a component in src/components/block, a docs page in src/content and a component test in tests/components, followed by a registry rebuild and the test run.

That is an unusual repository design, and it is the clearest statement of what this project is. The components are the product, and the pipeline that produces them is as much a part of the project as the components themselves.

## Generated manifests, and the checks that gate a change

Because the registry, the llms.txt and the Markdown docs are all derived from the component source, the build has a generation step that has to be remembered. The README names the two commands: npm run registry:build and npm run agent:build, which rebuild the shadcn registry, the llms.txt and the Markdown docs from source, so that a component the agent builds can be installed right away.

The package manifest is precise about what each command does. registry:build runs a script that rebuilds the installation manifests from component sources, and agent:build runs a script that rebuilds llms.txt, the Markdown pages and the agent route maps. The build script chains them, so a production build includes the registry and the agent artefacts.

The checks are layered. npm test runs the unit and component test suites, which are two separate commands, a node test runner for the unit tests and vitest for the components. npm run check adds lint, type checking and a production build, and the README describes the intent plainly: so Droid can prove a change works. A third script, npm run verify:agents, verifies the agent endpoints, and there is a typecheck script that runs the Next.js type generation before the compiler check.

The rule the AGENTS.md file encodes, that generated files are not hand-edited, is what keeps that pipeline honest, since a hand-edited manifest is the classic way a generated system starts to drift.

## Where the code lives and what the commands are for

The source layout is small and worth memorising, because it is the same in the prompts the README gives to the agent. The primitives live in src/components/ui, the blocks and effects live in src/components/block, and the documentation lives in src/content. A run of the local development server shows all three.

Running it locally is four commands from a fresh clone:

```bash
git clone https://github.com/Atharvsinh-codez/ObsidianUI.git
cd ObsidianUI
npm ci
npm run dev
```

and the site is then at localhost:3000, with the docs pages under localhost:3000/docs.

The command table in the README is the reference for the rest. The dev script starts the local development server, the build script builds the production site together with the registry manifests and the search index, and the postbuild step runs pagefind over the built output to produce a static search index. There are separate lint and typecheck scripts, the test scripts already mentioned, and a check script that runs lint, types, tests and the production build in sequence.

The stack behind it is modern by declaration, with badges for Next.js 16, React 19, Tailwind CSS v4 and TypeScript, plus Motion for animation and the shadcn registry as the delivery format. The dependency list also shows a large set of Radix UI packages, which is the usual foundation for accessible primitives, and a couple of more specialised packages such as number-flow for numeric display and a shader package for the effect components.

## Where ObsidianUI is the wrong tool

The first limit is the absence of versions. There are no GitHub releases, the package manifest is marked private with version 0.1.0, and the name of the package is obsidian-ui. That is consistent with the shadcn model, where the version lives in your own repository, but it means there is no upgrade path and no changelog to read when a component upstream is rewritten. A team that needs to audit what changed in a dependency has no mechanism here.

The second is the baseline. The project targets Next.js 16, React 19 and Tailwind CSS v4, and a component built on those is not a component you can drop into a React 17 codebase with a Tailwind v3 configuration. The Tailwind v4 move in particular changes how design tokens and configuration work, so the components are coupled to a specific generation of the styling toolchain.

The third is that the copied-source model has a cost the README does not price. Every install adds files, styles and local helpers to your tree. In a large project with many components from many sources, you end up maintaining a patchwork, and a component that depends on a helper file that a later install overwrites is a class of bug that no package manager would have let you have.

The fourth is maturity. Version 0.1.0, a private package, and a repository that was built by an agent rather than accumulated over years means the components have not been through the long tail of bug reports that a mature library has, and the components listed as made with Droid are new.

## Licence, repository hygiene and the state of the project

ObsidianUI is released under the MIT Licence, with the licence file at the root of the repository. Since the components are copied into your project rather than consumed from npm, that licence governs the files you receive, which is the part that matters for a commercial product.

The repository has a lot of files that are not code, and they describe the project's process rather than its output. There is AGENTS.md and ACEBUILDER.md for the agent workflow, AGENT_ACCESS.md, MCP.md for the Model Context Protocol server, PROJECT_REVIEW.md, TODO.md, CONTRIBUTING.md and GSoC_IDEAS.md, plus a skills directory and a scripts directory. The components.json file and the eslint, next, postcss and vitest configurations sit alongside the source.

The last push was on 2026-10-18 and the repository is not archived, so the work is current. There are no GitHub releases, so the site at obsidianui.dev is the release channel in practice, and the components page there is where you pick something to install. The contributing guide is described as the full walkthrough from creating a component to a working install command, which is a useful thing to read before contributing, and issues and pull requests are welcome.

One more file is worth a look before you plan around this project: the project review document in the repository root, which is where a maintainer would record their own assessment of the state of the work.

## Conclusion

ObsidianUI fits a React team that wants component source it can edit rather than a package it has to configure, and that is comfortable with Tailwind CSS v4, React 19 and Next.js 16 as the baseline. It is the wrong tool if you want versioned upgrades from a registry, since there are no GitHub releases and the package manifest is private and marked 0.1.0, and the wrong tool if you need a component library that your own engineers can extend through a supported public API rather than by editing copied files. Before you adopt it, check three things: that the shadcn CLI install command actually reaches your project, that you run npm run registry:build after any change to a component source, since the install manifests are generated, and that you are comfortable that the code that lands in your repository is code you now maintain. The project is MIT licensed, the last push was on 2026-10-18, and there are no GitHub releases.

## FAQ

### How do I install an ObsidianUI component?

Pick it from the component gallery on the site and install it with the shadcn CLI, for example `npx shadcn@latest add "https://www.obsidianui.dev/r/hover-img.json"`. The registry install adds editable files to your project, including the styles and local helpers a component needs.

### What happens after I change a component in the ObsidianUI repository?

You rebuild the generated output. `npm run registry:build` rebuilds the installation manifests from the component sources and `npm run agent:build` rebuilds llms.txt, the Markdown pages and the agent route maps, and the AGENTS.md file forbids hand-editing generated files.

### Can a coding agent use ObsidianUI?

Yes. The project publishes llms.txt, Markdown documentation, a public registry and a local Model Context Protocol server started with `npm run mcp`, and the repository is set up so an agent can take a component from idea to install command.

### How do I run ObsidianUI locally?

Clone the repository, run `npm ci` and then `npm run dev`, and open localhost:3000. The primitives are in src/components/ui, the blocks and effects in src/components/block, and the documentation in src/content.

### What is the licence and release state of ObsidianUI?

The project is released under the MIT Licence. There are no GitHub releases and the package manifest is marked private at version 0.1.0, so the site at obsidianui.dev is the distribution channel in practice. The last push to the repository was on 2026-10-18.

## Sources

- [Atharvsinh-codez/ObsidianUI on GitHub](https://github.com/Atharvsinh-codez/ObsidianUI)
- [Issues](https://github.com/Atharvsinh-codez/ObsidianUI/issues)
- [License: MIT](https://github.com/Atharvsinh-codez/ObsidianUI/blob/main/LICENSE)
- [Project website](https://obsidianui.dev)
- [README](https://github.com/Atharvsinh-codez/ObsidianUI/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/atharvsinh-codez-obsidianui