Starwind UI keeps your components in your repo and pushes framework support down into an adapter layer

The component count is 55, 54 and 36 depending on where you look

The repository description says 55 framework-portable UI components. The Svelte section says the beta provides the same 36 Primitive families and 54 portable Styled components as the other first-party adapters. Those numbers reconcile rather than conflict, because one component is deliberately excluded: Styled Image remains Astro-only, which is stated in both the Vue and the Svelte sections.

So the honest reading is 54 components that travel and one that does not. What the documentation does not give is the Vue count in its own words, since the 36 and 54 figures appear under Svelte and are asserted to match the other adapters rather than restated per framework. Anyone budgeting a migration should assume Vue matches and verify it against the generated output, because the Astro-only exclusion is the kind of detail that only surfaces when a component is missing at build time.

The 36 Primitive families are the behavioral layer. Those are the pieces that carry the accessible behavior the Runtime exposes, and they are counted separately because they are not the same thing as the styled components you end up owning.

Vue and Svelte both declare their own API unstable through 0.x

Astro and React initialize from the stable release with no flags. The other two adapters need a beta package and a framework flag:

npm install @starwind-ui/vue@beta vue@^3.5
npx starwind@latest init --framework vue

npm install @starwind-ui/svelte@beta "svelte@>=5.29.0 <6"
npx starwind@latest init --framework svelte

Both sections end with the same sentence in substance: the API can change during the 0.x series, and beta feedback belongs in the issue tracker. Two distinct caveats ride along. Vue adapters use idiomatic `v-model` arguments with matching `update:*` events and normal detailed event listeners, which is a different shape from the other adapters and worth checking against code you already have. And the supported project lists are not the same length: Vue names Vite Vue, Astro Vue, Nuxt 3 or 4, Laravel with Inertia Vue, and Quasar Vite in both SPA and SSR modes, while Svelte names Vite with Svelte, SvelteKit, and Astro with Svelte.

Starwind Pro has no Svelte setup path, and that is stated in one sentence

Between the two beta sections, one line carries the entire commercial boundary: Starwind Pro setup is not available for Svelte. Nothing else in the front page says what Pro contains, what it costs, or which frameworks it does cover. Astro and React are the stable line, so the reasonable assumption is that Pro is available there, but that is an inference from absence rather than something the page states.

For a Svelte shop this is the decision point. You can install the beta adapter and generate components, and you cannot configure the paid tier for it, with no stated roadmap for when that changes. Combined with the Styled Image exclusion and the 0.x instability note, the Svelte path has three separate caveats stacked on it while Astro has none.

The same asymmetry shows up in the packaging. TraeWork and WorkBuddy are not relevant here, but the distribution shape is worth naming: the CLI is published to npm as `starwind`, and the adapters as `@starwind-ui/vue` and `@starwind-ui/svelte`, so a Vue or Svelte project ends up depending on two packages from the same author, one stable and one on a beta tag.

Your components sit above the adapter, so a framework swap means rewriting markup you own

The Runtime architecture is drawn as a five-step chain, from your application down to the browser APIs: your application, the Starwind components you own as Tailwind CSS plus framework markup, the framework adapter, the shared framework-neutral Runtime, and finally the DOM.

The order matters. The components sit above the adapter, not below it, which is the practical consequence of the copy-it-in model. When you move from React to Vue, the Runtime and the adapter change underneath, and the files you have been editing and customizing have to be regenerated for the new framework's markup. You are not upgrading a dependency; you are reapplying your own edits on top of generated output.

That is the trade the project is making deliberately, and the description states it in one line: install accessible Tailwind CSS components as source you own. The front page points to `docs/portable-runtime/README.md` for current implementation details, so the Runtime's internals are documented outside the README rather than in it, and the mermaid diagram is the whole architecture description that sits on the page itself.

One format script chains three tools that all want to rewrite your files

The root `format` script is a pipeline rather than a single command:

prettier -w . --ignore-unknown --cache && eslint . --fix --cache && biome check --write --formatter-enabled=false --diagnostic-level=warn

Three tools run in sequence and two of them write files. Prettier formats, eslint fixes, and biome is invoked with its formatter disabled so it contributes imports and lint rather than layout. The split is defensible, but it is a split maintained by flags rather than by configuration, since the same biome binary appears elsewhere with formatting turned back on:

biome format && prettier -w . --ignore-unknown --cache --check

That is the continuous-integration variant for code, and a separate one runs `biome ci` with the formatter off for imports. Contributors touching formatting need to know which of the three tools owns a line, and the page describing the repository as a first-party library does not say anywhere which authority wins when they disagree. `ATTRIBUTION.md` and `AGENTS.md` sit in the root alongside `biome.jsonc`, `eslint.config.mjs` and `prettier.config.mjs`, so the inputs are all visible even if the precedence is not documented.

The default test command covers three projects, and the all-in-one chain names no Svelte entry

Vitest is configured with named projects, and the everyday commands select three of them by name:

vitest --project=repo-scripts --project=cli --project=portable-runtime

So the portable Runtime has its own test project in the default set, while the per-framework adapter tests sit behind a different command. The all-in-one script chains four further steps onto that base run:

pnpm test:run && pnpm runtime:test && pnpm react:test && pnpm vue:test && pnpm test:form-parity

The visible list names runtime, react, vue and a form parity step. No Svelte entry appears in it, and a separate command covers only the repo scripts and the CLI. For a project whose selling point is four adapters behaving identically, that asymmetry is the first thing a contributor should raise, because it is the difference between a shared Runtime being tested as shared and each adapter being tested against it.

Four published packages, one tag, and two releases on the same afternoon

This is a monorepo: a workspace file, a Turbo pipeline, and a `packages/` directory, from which the build script selects `@starwind-ui/runtime`, `@starwind-ui/astro`, `@starwind-ui/react`, `@starwind-ui/vue`, `@starwind-ui/svelte`, `starwind` and four demo apps. The root `package.json` is named `root` and pinned at version 0.0.0, private, with module type set to `module`.

What that means for consumers is that one repository tag does not tell you which package versions moved. The recent history is three tags: v3.3.0 and v3.3.1 both on 2026-09-05, six hours apart, then v3.3.2 on 2026-09-06. The last push to the default branch is dated 2026-09-28, and a `.changeset/` directory at the root indicates the release notes are assembled from changeset entries rather than written by hand. Neither the tag names nor the README says how a changeset covering only one adapter is surfaced to someone pinning `@starwind-ui/svelte@beta`, which is the case where version confusion would actually bite.

The CLI lives in this repository too, under `packages/cli`, and the front page redirects anyone looking for the main package to that directory's own README rather than documenting it here.

The repo ships four separate surfaces for AI agents

Starwind treats agent-facing context as a first-class deliverable, and there are four of them on the front page: a Skills page, an MCP server page, `llms.txt` and `llms-full.txt`. The two text files are the familiar convention, a short index and a full dump, and the other two are integrations an agent can actually call.

The repository itself carries the matching files. `AGENTS.md` sits in the root and an `ai-context/` directory sits beside `apps/`, `docs/` and `scripts/`, which suggests the context an agent reads is versioned with the code rather than pasted into a documentation site and left to rot.

This is the shape a component library takes when its consumers are partly machines. A human reads the docs pages; an agent reads the text files, the skills entry and the MCP server. Whether those four surfaces stay in step is the operational question, and the front page gives no way to check it, since the version each surface was generated for is not stated anywhere on the page.

Editorial conclusion

Starwind UI is a good fit for a team that wants shadcn-style source ownership without giving up framework switching, and for anyone already inside Tailwind CSS v4 who wants keyboard-navigable components without hand-rolling focus management. It is a weaker fit if you need the Vue or Svelte adapter to be settled, since both are public beta, both say the API can change through the 0.x series, and the Svelte path has no Starwind Pro setup at all. Two things to check before you commit. Styled Image exists only on Astro, so a plan that assumes five adapters means it has to work around one missing component on the other four. And the single `npx starwind@latest init` path defaults to the stable Astro or React line, so picking Vue or Svelte means pinning beta package versions yourself and accepting that the CLI flag only handles initialization. On the licensing side the repository is MIT and carries an attribution file, which is the ordinary arrangement for a component set meant to be copied into your codebase rather than consumed as a dependency. What it does not replace is a component library you intend to consume from a registry: the point of the design is that you end up owning the markup, so future upgrades to the Runtime arrive as diffs you have to read.

Frequently asked questions

Official sources

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