No manifest in your repo is a real design choice

It composes two CLIs instead of shipping a template

The pipeline in the README is the whole architecture, and it is worth reading as a list rather than a diagram. The CLI prompts, then the official shadcn/ui init runs, then the official create-tauri-app setup runs, then the frontend and the native shell are combined, then desktop-ready defaults are applied, then the optional batteries are added. The last line of that section is the sentence that matters, that there are no full local templates and only a small asset and patch surface on top of the upstream CLIs. Compare that with the usual scaffolder, which copies a directory of files into your project and then never touches it again. The consequence of the composer's approach is that your project is generated by two upstream tools, so when shadcn changes its init or create-tauri-app changes its output, your next scaffold reflects that rather than being frozen at whatever date the template was written. The cost is that your project is not reproducible without those two tools at the versions they were at, and the README's insistence that nothing forks is a claim about that exposure rather than a promise of stability.

Five desktop defaults, and they are the product

The README frames the problem as a fresh Tauri app feeling like a wrapped website, and then lists the chores you hit on every project: window state, startup flash, link routing, overscroll, native selection. The default battery answers each one. No startup flash, with the window hidden until the first paint, which is the difference between an app that appears and an app that fades in over your desktop. External links open in the system browser rather than inside the webview, which stops a link from replacing your desktop application with a web page. No overscroll or rubber-band scrolling, because that gesture is a mobile affordance and feels wrong under a mouse. Desktop-style selection behaviour, so text does not highlight the way it does on a touch device. And a sensible default window size and position, which you can then adjust in the native configuration file the README points at. Five behaviours, all of them things a web page does by default and a desktop application should not, and none of them the kind of decision you want to make per project.

The debug panel shows you which layer a value came from

The most interesting optional extra is a debug panel on a keyboard shortcut, and the reason it is interesting is not that it dumps state. It inspects application state, the route, the window, tracked invocations, runtime events, plugin logs and system paths, and it adds live host diagnostics for theme and accessibility, locale, display, input and network. Then one detail carries the whole idea: hovering a field shows the source snippet with an origin chip marking whether it came from the web layer or from Tauri, and clicking copies it. In a framework whose entire conceptual difficulty is that half your state lives in a webview and half lives in a native process, labelling the provenance of every value is the feature a newcomer needs and nobody else has built. The panel is described as development-only with zero production impact, it docks, and it remembers its layout, which are the three details that separate a tool you will keep open from a debug menu you open once.

Batteries are managed by a CLI that writes nothing to your repository

The after-scaffold commands are the ones to copy into your notes, because they are the ongoing relationship with the tool. Inside an existing project, the same executable lists what is installed, updates one battery, adds one, and removes one:

bunx create-tauri-ui@latest list                  # show install status
bunx create-tauri-ui@latest update debug-panel    # pull the latest template
bunx create-tauri-ui@latest add workflow          # add the release workflow later
bunx create-tauri-ui@latest remove workflow

The note above that block is the design decision worth arguing about. The template is auto-detected, no manifest file is written into your repository, updates are idempotent, and you are asked to commit first and review the diff. The benefit is that there is no project-level state file to drift out of sync with reality, and no generated file for a merge conflict to fight over. The cost is that the only record of what is installed is your git history, which means a new maintainer has to read diffs to find out, and that a battery added by one developer is invisible to a teammate until they look at the source directory. For a solo project that trade is clearly right. For a team, the commit-and-review instruction is doing the work that a manifest would otherwise do.

Being legible to a coding agent is a stated goal

One line in the why section is easy to skim and is probably the most forward-looking thing in the README, that this is better with AI coding agents because the structure is a familiar shadcn and Tauri shape built on upstream APIs without custom wrappers or forks. Consider what a scaffolder that invented its own component API would produce: a codebase whose conventions appear nowhere in the training data, where every generated import is unfamiliar, where the model guesses at a design system that does not exist, and where every suggestion it makes has to be checked against a framework you have never read. By refusing to fork and refusing to wrap, this tool produces the closest thing to a default Tauri application that already exists, which is exactly the shape a model has seen. The same argument explains the absence of a template. A template is a private format; upstream plus a patch is a public one. The batteries, including the debug panel, the external link guard and the theme provider, live as ordinary components under a components directory in your source, which means they are readable, editable and deletable rather than being a layer you have to accept.

Five adapters, because the same defaults have to hold five times

The choice of frontend is Vite, Next.js, React Router, Astro or TanStack Start, and the feature list calls the resulting set adapters. That is the part of the project that looks like a feature list and is actually a maintenance obligation. Tauri's native shell is frontend-agnostic, so every one of those build systems can sit inside it, which means the same five desktop behaviours have to be applied correctly to five different module loaders, five dev servers and five sets of entry point conventions. A startup flash fix is a single script tag in one of them and a plugin configuration in another. The repository description mentions Vite, Next.js, Astro and TanStack Start, and the body adds React Router, so the fifth was added later, and adding an adapter is a piece of work rather than a switch. The optional extras follow the same logic, with a starter dashboard, a Rust invocation example, a GitHub Actions release workflow, and a binary size reduction that the README attributes to a test of its own rather than to a measurement you can check.

A release carries a demo build of the output

Every release includes a demo build showing the expected output, and the README says so next to the install command. For a scaffolder this is the most valuable thing it could publish, because the failure mode is not an error message, it is a project that installs cleanly and is subtly wrong, with a window that flashes, a link that opens inside the app and a scroll behaviour that feels borrowed from a phone. A build of the result makes the promise checkable before you commit an afternoon to it, and it also pins the expectation to a version, which matters for a tool that composes upstream CLIs whose output can change underneath it. The install itself is one command, and the after-scaffold step is two:

bunx create-tauri-ui@latest

then a change into the generated directory and a run of the development server through the Tauri script. From there the README lists the four things you will actually do next, generating the icon set from a source image, adding shadcn components through its own CLI, adding Tauri plugins through the Tauri CLI, and adjusting window defaults in the native configuration file. Each of those is an upstream tool rather than a tauri-ui command, which is the design principle restated one more time.

A monorepo on bun, turbo, changesets and a Rust linter

The repository is small and the tooling tells you what kind of project it is. The root package is private with workspaces for the applications and packages directories, and almost every script delegates to turbo, including build, development and type checking. Releases go through changesets, with a dedicated script for versioning packages and another for publishing, and there is a changesets directory at the root. Linting and formatting are oxlint and oxfmt, both of which are the Rust-based tools in that ecosystem rather than the JavaScript linting stack, configured through two small files at the root. Tests are four named scripts for the CLI itself, covering a simple path, a release path, a workflow path and a full path, run from scripts with a mix of Node and Bun depending on the file. Accessibility is not an afterthought here: taze appears in the scripts with a minor and a major variant, which is an accessibility checker run as part of the test surface. The declared runtime is Node 18 or newer with Bun as the package manager at a pinned version and TypeScript pinned to a version 7 release, so this is a project tracking the current generation of its toolchain rather than a conservative one.

Editorial conclusion

Adopt create-tauri-ui if you are starting a Tauri v2 desktop app with a shadcn interface and you would rather not spend the first afternoon fixing the five things that make a fresh Tauri app feel like a website. Do not adopt it if you have an existing project, since the tool is built around the scaffold moment, and read the upstream Tauri and shadcn documentation yourself before you start, because the whole design is that you stay close to them. Verify four things: that the adapter you want is one of the five listed, which are Vite, Next.js, React Router, Astro and TanStack Start, that the demo build attached to the release you are installing shows the output you expect, that you are comfortable with the debug panel shipping as one of the default batteries in src/components/, and that you commit before running the update command, which the README asks for explicitly. The licence is MIT, the latest package version is create-tauri-ui 1.2.0 from 2026-08-01, and the last push to master is the same day.

Frequently asked questions

Official sources

1. agmmnn/tauri-ui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases