AgnosticUI Local v2: a CLI that copies Lit components into your repo
AgnosticUI Local (v2) is a CLI-based UI component library that copies components directly into your project. Works with AI tools, agent-driven UIs, and prompt-ready workflows.
At a glance
- What is it?
- AgnosticUI Local v2 ejects framework-wrapped Web Components into src/components/ag/ instead of resolving them from node_modules. The trade is source ownership and LLM-readable context in exchange for vendored code you now maintain.
- Who is it for?
- Adopt AgnosticUI Local v2 if you want the component source inside your repository, you accept that upgrades become merges rather than a version bump, and you are willing to read v2/docs/schema-coverage.md before assuming a component exists in the schema-driven layer. Do not adopt it if you want a dependency you can update with a lockfile change, or if your team has no process for reviewing vendored source.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 77 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is node_modules opacity, and the audience is teams using coding agents
Most component libraries ship as a package you import. The source stays in node_modules, the public surface is whatever the maintainers export, and an AI coding assistant reading your repository sees only the import statement. When it needs to know which props a Button accepts, it guesses. AgnosticUI Local v2 takes the opposite position: the CLI copies component source into your project at install time, so the files sit alongside your own code. The README frames this as solving the "Black Box" problem, and the claim about hallucination follows from it. An agent that can read Button.vue and Button.css does not need to invent an API.
The intended user is not every frontend team. It is a team that already runs Cursor, Claude, Copilot, Windsurf, Aider, Gemini, Replit, Kiro or Antigravity against its repository and wants the UI layer to be part of the readable context. The secondary audience is anyone who has been burned by a component library that changes behaviour under a minor version, since vendored source cannot change without a commit in your history.
Lit core, CLI wrapper, and a schema-driven layer with its own documents
Components are authored once as Lit Web Components, which the README describes as a standards-based layer over native Custom Elements. The CLI does the framework translation at copy time. So a Vue project receives Button.vue, a React project receives the React-shaped equivalent, and both trace back to the same Lit definition. The README's architecture graphic puts it plainly: AI Playbooks direct the Lit Core, which the CLI ejects into React, Vue and Svelte.
The data flow for the newer schema-driven work is documented separately. There is an AgNode[] graph model, a codegen pipeline, renderers, and CI gates, described in v2/docs/sdui-architecture.md. A prompt guide at v2/docs/llm-prompt-guide.md holds a copy-paste system prompt and few-shot examples for generating valid AgNode[] graphs. A third file, v2/docs/schema-coverage.md, is a per-component registry of SDUI coverage, renderer parity status, and reasons a component was omitted. That third document is the one to read before planning anything, because it is the project's own admission that the schema layer is not uniform across components.
Two commands and a namespace directory
Installation is a two-step CLI flow. From your project root:
cd your-project npx agnosticui-cli init --framework vue npx agnosticui-cli add Button Card Input
The init step takes a framework flag; the README shows vue and names react, lit and svelte as the other accepted values. The add step takes a list of component names. After that, files land under src/components/ag/ by default, in a per-component folder:
src/components/ag/Button/Button.vue src/components/ag/Button/Button.css src/components/ag/Button/Button.test.ts
The ag namespace exists to keep library components separate from your own, and the README states it is configurable if you prefer a different location. Tests arrive with the components, which is unusual for a copied-source model and means your test runner will pick them up unless you exclude the directory. The README also claims zero runtime dependency after ejection, which is consistent with source-in-repo but is a claim about the ejected output rather than something the README demonstrates.
Vendored source means upgrades are merges, not version bumps
The README's comparison table lists source-in-repo, framework-agnostic core, local LLM readability and zero runtime dependency as AgnosticUI's advantages. It does not list the cost. Once Button.vue is your file, a fix upstream does not reach you through a package manager. You either re-run the CLI and reconcile the diff against whatever you changed, or you stop tracking upstream. Neither is free, and the README does not describe an update command or a merge strategy.
The release data reinforces the point. The most recent releases listed are v1.0.3-13, v1.0.3-12 and v1.0.3-4, all dated October 2020, while the last push to the repository is dated 2026-06-30. The v2 work described in the README therefore appears to be happening on the branch rather than through tagged releases. If you adopt from master, you are tracking a moving branch, and with copied source that means re-reading diffs rather than bumping a version string. Anyone who needs a stable, tagged artifact should confirm what is actually published before committing.
When a component library you import is the better answer
The direct alternative is a conventional packaged library in the same space, such as Shoelace or its successor Web Awesome, which also build on Web Components and ship as installable packages. The difference in approach is where the source lives. With a packaged library you add a dependency, import the custom element registration, and update by changing a version. You get fixes without touching your code, and you give up the ability to read or edit the component internals. AgnosticUI inverts both halves of that trade.
That inversion is wrong for some teams. If your components are stable, your design does not diverge from the library's, and your priority is a small diff surface on upgrade, a package is the lower-cost choice. The vendored model pays off specifically when you expect to modify components, or when the value you are extracting is agent-readable context rather than the components themselves. A team that copies the files and never opens them has taken on maintenance without collecting the benefit.
Apache-2.0 and the practical cost of owning the source
The repository is licensed Apache-2.0, which is a permissive licence that includes an explicit patent grant and requires attribution and notice retention on redistribution. Because the CLI copies source into your repository, the copied files are the ones you would be redistributing if you ship them, so the licence and notice obligations attach to files you now own a copy of. This is a description of the licence's general shape, not legal advice; check the bundled licence text and your own counsel for what your distribution requires.
Maintenance cost is the more concrete number. Every component you add is a set of files in your repository that your team reviews, formats, lints and tests. The README notes the components arrive with tests, so your CI configuration needs to either run them or exclude src/components/ag/. Multiply that by the number of components and the number of frameworks if you run more than one. The Playbooks add a second surface: Login, Onboarding, Discovery Dashboard, Support Center, Data Grid, Blog and Landing are described as prompt-driven scaffolds rather than installed packages, so using them means generating code from a prompt and then owning the result.
What the README leaves unresolved
Several things a team would want to know are not in the supplied material. There is no documented update or sync command, so the upgrade path for vendored components is unspecified. There is no statement about how the React, Vue and Svelte wrappers are kept in sync with the Lit core when the core changes. The schema-driven layer's coverage is explicitly partial by the project's own registry, but the README does not say how partial. The Playbooks section is truncated mid-sentence in the material available, so the full list of what each one generates cannot be confirmed.
None of this makes the project unusable. It means the decision rests on reading v2/docs/schema-coverage.md and v2/docs/sdui-architecture.md directly rather than on the README's framing, and on accepting that the CLI's init and add commands are the whole documented workflow. If those two documents show the components you need with renderer parity, the model works. If they show gaps, you will be filling them yourself, in your own repository, which is exactly what copying the source commits you to.
Editorial conclusion
Adopt AgnosticUI Local v2 if you want the component source inside your repository, you accept that upgrades become merges rather than a version bump, and you are willing to read v2/docs/schema-coverage.md before assuming a component exists in the schema-driven layer. Do not adopt it if you want a dependency you can update with a lockfile change, or if your team has no process for reviewing vendored source. Verify three things first: that the framework you target is one of the four the CLI accepts, that the components you need appear in the coverage registry, and what the Apache-2.0 licence requires you to keep when you redistribute the copied files.
Community notes