What it is
Sona UI is an animated component library for React and Tailwind CSS. It distributes components as source code through a shadcn registry, instead of as a package imported at runtime. Its documented components include accordions, animated dialogs, animated dropdowns, expanding actions, fluid tabs, and fluid tooltips.
It is a component library, not a DESIGN.md format or a general-purpose design extractor. What makes it interesting for this survey is the number of machine-readable surfaces it publishes for agents: llms.txt, a manifest, a catalog, an OpenAPI description, and a skill distributed through the registry.
First principles
A component library can reach a project in two ways. As a package, the code stays in a dependency and changes when the version changes. As source, the code is copied into the project and belongs to it from then on. Source ownership trades an easy upgrade path for full control: a team can read and edit every line, but updates do not arrive on their own.
An agent adds a second constraint: its knowledge is a snapshot. A model’s training data, and any cached copy of a catalog, are older than the live registry. An agent that picks components from memory may choose one that has changed or no longer exists.
Sona UI’s design follows from both points. Components install as source, so the consuming team owns them. And llms.txt tells the agent to fetch the live manifest before choosing, and to say so when it cannot. Freshness becomes an explicit step instead of an assumption.
Who is behind it
Sona UI is made by solo developer Dinil Thilakarathne, whose GitHub profile is named in the site metadata. The repository is MIT licensed, was created on 2025-04-11, and was last pushed on 2026-09-15. As of September 2026 it had 116 stars, 5 forks, and no open issues. The author also links GitHub Sponsors and a separate product, Tracwell.
This is a real, actively maintained small project, with the continuity limits of a solo-maintainer effort.
Format and how an agent consumes it
Components install into the consumer’s repository through the shadcn registry:
npx shadcn@latest init
npx shadcn@latest add @sona-ui/magnetic-button
The registry declaration is a standard JavaScript Object Notation (JSON) entry:
{
"registries": {
"@sona-ui": { "url": "https://sonaui.com/r/{name}.json" }
}
}
It also distributes an agent skill from the same registry:
bunx shadcn@latest init
bunx shadcn@latest add @sona-ui/agent-skill
The strongest part is llms.txt, which tells an agent how to refresh its knowledge:
## Freshness protocol
Before selecting or installing a component, fetch the agent manifest and follow its catalog URL. The manifest is the current authority when network access is available.
If the manifest cannot be reached, disclose that the installed or downloaded snapshot may be older than production.
The same file links to agent/manifest.json, agent/catalog.json, llms-full.txt, the registry index, and openapi.json. Sona UI does not need a custom Model Context Protocol (MCP) server. It uses the official shadcn MCP server for Claude Code, Cursor, and Codex. Its suggested workflow is to describe the interaction rather than name a component, inspect the match, install it, and then validate type checking, keyboard behavior, theme behavior, and reduced-motion behavior.
Pricing and access
Sona UI is free and MIT licensed for personal and commercial use. Its /pricing route returned a 404 (not found) error in the research. GitHub Sponsors is the visible funding route; there is no paid product tier.
What works
Sona UI’s distribution is concrete. Installed source belongs to the consuming project, so a team can read and change it without being locked to a runtime dependency. More unusually, the agent-discovery stack is layered. Human-readable context, JSON discovery, OpenAPI, an installable skill, and a registry each have a defined role.
The freshness protocol is a strong operational detail. It accepts that a cached agent snapshot can be stale and tells the agent to say so. The guidance also covers accessibility and reduced motion, instead of treating animation as decoration only.
What does not
The documented catalog is small, roughly 6 to 7 components at the research date. The project relies on shadcn’s MCP integration rather than providing its own agent tools. Any portable design-token format beyond Tailwind and Cascading Style Sheets (CSS) variables is UNVERIFIED, because the theming documentation was not examined in depth.
There is also the usual solo-maintainer risk. A layered discovery surface helps only while the manifest and catalog stay current.
What we take from it
Velofy could propose the same layered discovery pattern: llms.txt for a readable overview, a JSON manifest and catalog for programs, OpenAPI for tools, and a skill for supported agents. It could require a freshness check before an agent uses a cached design artifact.
These are proposals, not existing Velofy services. Velofy has not shipped a component registry, package, or MCP server. The lasting lesson is that content meant for agents needs both a representation and a way to say which version is current.