Starwind UI

Astro-first, framework-portable UI components you can own.

Starwind UI gives you accessible, Tailwind CSS components with Starwind/shadcn-style ergonomics,
backed by a portable Runtime that powers Astro and React adapters today.

Explore Components

Why Starwind?

🎯 Own Your Code — Styled components live in your project, where you can understand and customize them.
✨ Animated by Default — Smooth, polished animations out of the box with Tailwind CSS v4.
♿ Accessible — Keyboard navigable and screen reader friendly. Built with a11y in mind.
🚀 Portable Runtime — Shared DOM behavior with generated Astro and React adapters.
🛠️ CLI-Powered — Add only what you need with a simple npx starwind add command.

Looking for the main package? See starwind-ui/cli.

Get Started

Initialize an Astro or React project with the stable release:

npx starwind@latest init

Then add the components you need:

npx starwind@latest add

Runtime Architecture

Starwind components use a framework adapter backed by the shared, framework-neutral Runtime.

flowchart TD
  App["Your application"]
  Components["Starwind components you own<br/>Tailwind CSS + framework markup"]
  Adapter["Framework adapter<br/>Astro or React"]
  Runtime["Starwind Runtime<br/>shared accessible behavior"]
  Browser["Browser APIs and the DOM"]

  App --> Components
  Components --> Adapter
  Adapter --> Runtime
  Runtime --> Browser

See Portable Runtime for the current implementation details.

AI integration

Resources for AI:

Contributing

Please read the contributing guide.

License

Licensed under the MIT license.

Built with Codex and GPT-5.6

Starwind UI existed before OpenAI Build Week. During the submission period beginning July 13,
2026, I used Codex with GPT-5.6 as my primary engineering collaborator to materially extend and
harden the portable Runtime. GPT-5.6 is part of the development workflow through Codex; it is
not a runtime dependency of the components that Starwind users install.

Codex accelerated work across the project:

Architecture and decisions — Codex helped inspect the existing system, compare alternatives,
stress-test boundaries, and document decisions such as the DOM-first Runtime, separate Primitive
and styled adapter layers, framework target homes, and native-first form behavior.
Implementation — I used Codex to turn approved specs into dependency-aware tickets, implement
them in isolated Git worktrees, and independently review each slice. During Build Week this
included Color Picker productization, tighter Runtime boundaries, cross-framework lifecycle
fixes, public documentation work, and release hardening.
Testing and debugging — Codex built focused reproduction loops and regression coverage across
Runtime unit tests, Playwright browser tests, deterministic generator tests, CLI and registry
tests, Astro and React demos, and published-package acceptance fixtures.
Performance and package discipline — Codex helped create and interpret repeatable browser
benchmarks, minified-and-gzipped bundle comparisons, tree-shaking checks, and release-blocking
size budgets instead of relying on intuition about performance.
Durable agent workflows — Project-specific Codex skills, context documents, specs, ticket
queues, reviewer contracts, and completion evidence keep architectural knowledge available across
sessions and make future changes safer for both humans and agents.

The key decisions and results are visible in the
portable Runtime documentation,
framework readiness gate,
performance comparison,
package-size comparison, and the repository's
commit history.